Main and visibly apparent difference between n-tier and clean architecture

Question

Disclaimer. I'm not looking for a discussion or opinions of those two. Nor do I aim at evaluating or describing them. I'm in a project where I'm supposed to set up a path to refactor from the traditional to the domain driven one and I wish to keep the changes as small as possible still achieving the task.

According to MS docs for clean architecture, the onion shaped diagram is supposed to differ from the n-tier architecture, which is layer shaped.

It all makes sense while reading but then, a different view of the clean architecture is presented and it looks quite similar to the n-tier architecture. Of course, I do understand that those differ but trying to understand the core point on where and how they differ doesn't get easier by that resemblance.

An even better example of my the reason for my uncertainty is this blog. It's not .NET related but architecture ought to be technologically agnostic. As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).

Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?

Curarize

Answer 1

As far I understand, the actual path of the process is layer based and precisely equivalent to n-tier version (only differing in how it's drawn, which should be irrelevant).

Yes, that's right.

Is the main difference between those two architecture types simply how we're using them or is there an actual difference code-wise or in the project structure (except for the naming, of course)?

The difference is which code knows about, has references to, depends on other code.

In N-Tier, the business logic needs to know the API of the infrastructure layer. All of the dependencies point down.

In clean architecture/onion architecture, etc, the infrastructure layer knows about the API of the domain layer. All of the dependencies point inward.

Clean architecture puts the business logic and application model at the center of the application. Instead of having business logic depend on data access or other infrastructure concerns, this dependency is inverted: infrastructure and implementation details depend on the Application Core.

This style is often accompanied by the use of a Composition Root, which is responsible for wiring together the components that will eventually do the work.

Are you saying that there's no business logic layer in onion version? I.e. that it's baked in into the application core?

Typically, business logic is understood to be in the middle of the onion. For instance, Robert Martin offers

You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards.

Fulgurite

Thanks for the reply. I think you helped me pinpoint where I get confused. Are you saying that there's no business logic layer in onion version? I.e. that it's baked in into the application core? – Curarize

@DonkeyBanana: Business logic in DDD is in your aggregate roots and domain services – Correlate

Thank you for the clarification. I believe I'm starting to see the difference that's springs from it. One thing that caught my attention, though, is that the image puts DB in the outermost layer while the classes are in the innermost core. What does it imply for the files' placement in the projects? I guess all the models are put in the core project but where do the context go? (Contex being the class that inherits from DbContext while working with EF and code first approach.) Is it put in the model (although it's a DB creator feature)? In the DB projects? Infra? – Curarize

I was still a bit uncertain on a few details so I put a bounty on the question to draw attention and get more specifics. I see that there's been zero amended info, regrettably. This gives me the impression that the DDD approach is an interesting but vague concept. As if everyone's talking about it but when it comes to the actual implementations, people in general are unclear on how-to... Is that the case? – Curarize

It really doesn't imply anything about the location of source files. They might all be together in the same compilation unit, they might be in completely different repositories. You may find it useful to review the literature for "package by feature". – Fulgurite