Skip to content
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

Closed
mpszczolinski opened this issue May 25, 2023 · 3 comments
Closed

Example needed for onion-architecture #7

mpszczolinski opened this issue May 25, 2023 · 3 comments

Comments

@mpszczolinski
Copy link

Hey,

I am myself advocate of onion architecture.

You said:

we gave it all up in favour of the good old dependency inversion principle

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

@zakirullin
Copy link
Owner

zakirullin commented May 31, 2023

@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.

3 different layers.

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.

@zakirullin
Copy link
Owner

zakirullin commented Jun 1, 2023

cb424e1
d1fe571

@zakirullin
Copy link
Owner

#24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants