I don't know of open source apps that I can point to that would implement something like Clean Architecture, but I would wholeheartedly recommend Uncle Bob's approach to frameworks: don't.
At least, not in the way that framework authors recommend using it. In his words, using a framework and accepting its idiomatic contract means you also sign up to being completely bound to it. You're married to it, and a divorce can be costly.
The way he recommends approaching the problem is to have a layered approach where you treat everything that doesn't deal with your business rules as a plugin to your business rules and entities.
Say you're writing an accountint app. Why would you put your business rules into Models, which inherit ActiveRecord, which in turn implements some SQL that indirectly limits what kinds of interactions your objects can perform?
To him, the database is just a plugin, a detail. The web (HTML, JS, CSS, HTTP, etc.) is a detail. If the code that uses the framework depends on your business rules by importing from a gem, npm, jar, dll or whatever package mechanism you use, you will never be dependent on a particular framework.
Sure, building a REST server or choosing React as your view library is fine, but don't extend those objects with your logic. Create objects within the framework that depend on your logic! If you ever need to switch from Rails to Next, ASP.NET MVC or Spring, it's just a matter of binding a different frontend to the same logic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know of open source apps that I can point to that would implement something like Clean Architecture, but I would wholeheartedly recommend Uncle Bob's approach to frameworks: don't.
At least, not in the way that framework authors recommend using it. In his words, using a framework and accepting its idiomatic contract means you also sign up to being completely bound to it. You're married to it, and a divorce can be costly.
The way he recommends approaching the problem is to have a layered approach where you treat everything that doesn't deal with your business rules as a plugin to your business rules and entities.
Say you're writing an accountint app. Why would you put your business rules into Models, which inherit ActiveRecord, which in turn implements some SQL that indirectly limits what kinds of interactions your objects can perform?
To him, the database is just a plugin, a detail. The web (HTML, JS, CSS, HTTP, etc.) is a detail. If the code that uses the framework depends on your business rules by importing from a
gem,npm,jar,dllor whatever package mechanism you use, you will never be dependent on a particular framework.Sure, building a REST server or choosing React as your view library is fine, but don't extend those objects with your logic. Create objects within the framework that depend on your logic! If you ever need to switch from Rails to Next, ASP.NET MVC or Spring, it's just a matter of binding a different frontend to the same logic.