Add Clean Architecture to architectures
bit-jkraushaar opened this issue · 6 comments
I've checked if this was proposed in the past, but have not found anything on this topic.
I love the idea of xmolecules / jmolecules, but I miss Clean Architecture as alternative to Onion and Hexagonal architecture.
Are there any circumstances which prohibit implementation of this architecture? (e.g., licensing issues)
There's no real impediment to doing this except the question: what would that look like? Uncle Bob's article basically used Onion Architect, gave the rings different names, and made up a new word that could be associated with him. There are folks, that claim it's not even a new, separate style.
In other words, I wonder how useful it is to basically copy the OA implementation and rename the rings. IMO, CA only adds negligible (if at all) value over the “alternatives” (which they really aren't because they're effectively the same).
I agree that both architectures look very similar. I also agree that it is possible to use the existing Onion Architecture annotations to represent Clean Architectures. In my opinion, the meaning of the layers slightly differs from OA to CA. I also think that CA is a little bit more rigid regarding how data passes the layer boundaries.
In my understanding, xmolecules is all about making architecture explicit in the code. If a team decides to adopt Clean Architecture (even if some people may say it's only a relabeled OA), it would be nice to make it explicit using dedicated annotations.
Let's open this up a little. We would need a set of well-defined, sort of specified concepts and some sort of authority to point to (at least a blog post or the like) that we could introduce annotations for. What would also be beneficial is a set of relationship rules between these concepts. Happy to take suggestions for such an arrangement.
Based on the previously mentioned article, I propose the following concepts:
- Interface Adapter Ring: Presenters, Gateways, Controllers
- Application Business Rules Ring: Use Cases
- Enterprise Business Rules Ring: Entities
- Frameworks & Drivers Ring: UI, Web, Devices, DB, External Interfaces
Furthermore: All dependencies are directed inwards. That means also that controllers are not allowed to access gateways. At the borders between the rings only simple data structures may be exchanged.
The book defines some more, stricter rules (I had to quote them from the head, because I am just moving and have already packed the book away):
- Dependency always only on abstractions
- Dependency always only from the next lower ring
- Framework code only in the outermost ring
To be honest, though, I've mostly bent these stricter rules in my projects so far. Sometimes pragmatism wins over strict adherence to rules. ;-)
Putting the Frameworks & Drivers Ring to the side as it describes externals to the system, not parts of it, we are basically back at the Infrastructure (Interface Adapter Ring), Application (Application Business Ring), Domain (Enterprise Business Rules Ring) arrangement of Onion Architecture with exact the same dependency rules, aren't we?
What I think is also a bit unfortunate, and IMO proof that the entire remix of existing ideas is actually of less quality than the originals that have inspired it, is that the core of the system is dumbed down to “entities”, a term that had been established in the DDD context at the time CA was originally described.
How about this compromise: we create a way to further describe the existing annotations from the Onion architecture, e.g. using a "description" property (working term) or a custom annotation.
As I wrote before, I am aware that the two architectures are very similar. The main point is to make the decision for one or the other architecture explicit in the code.