-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example needed for onion-architecture #7
Comments
@mpszczolinski Hi there! The onion architecture variation I know implies using layers like: domain model, domain services, application services, infrastructure. Which is more layers than you described.
For me, Palermo, and some other people onion architecture is about 4+ different layers. The point is, we tend to understand these kind of things in our own way. Then we build on this understanding. Then we have to transfer this understanding to our colleagues. And this is hard. People spend time arguing whether their code should be placed in application services layer or domain services layer. People start thinking in terms of horizontal layers. If we spend time thinking about splitting our code into so many horizontal layers, we will not have much mental capacity left for more important things. Important things like vertical slices, isolation, cohesion and so on. Layers of abstractions aren't cheap, we should not add them blindly just everywhere. If I need some truly infrastructure-independent business logic, no problem, I will use DIP. But I won't split my logic into "domain" or "business logic" layers, because it may confuse others. It is confusing me already, because those two layers you suggested (domain and business logic) for me are the same thing. I won't name it "Onion Architecture" either. Because even between two of us there's a different understanding of this onion architecture. DIP turns out to be a much simpler and harder to misinterpret, whereas providing the exact same benefit. |
Hey,
I am myself advocate of onion architecture.
You said:
I'd like to see an example, as for me, doing onion architecture is mainly "dependency inversion principle" plus keeping DOMAIN, BUSINESS LOGIC (Use cases) and INFRASTRUCTURE in 3 different layers, glued together with "dependency inversion principle".
I'd love to see explanation how "favour of the good old dependency inversion principle" is different from "onion architecture" so I can better understand that section.
best regards,
Maciej
The text was updated successfully, but these errors were encountered: