Where should the business logic for a project that utilizes Onion Architecture be placed?
In my case, it's a C#-based project, utilizing Web API and possibly a MVC UI for the presentation. But that may not matter, since I'm just curious about this conceptually.
The two diagrams below seem to be the most common ones that appear all over the web when I'm Googling info on onion architecture:
Enlarged images: diagram 1 and diagram 2
If I'm not mistaken, anything below the outer ring is considered the Core.
In Diagram #1 the most outer of the Core (blue ring) contains service interfaces, and it shows that the purple outer ring has the logging, services, etc. So does that mean the outer purple ring contains the service layer and business logic?
In Diagram #2 it shows Application and Domain Services as a part of the Application Core (not just interfaces and the domain model).
I feel that these two diagrams seem to define Onion Architecture completely different, but yet they seem to be the two primarily referenced. Or am I reading this wrong?
Maybe the end-result is no different, and it's just a matter of how I'm viewing the project layout in my head, but I've been trying to think of the service layer as a part of the Infrastructure on the outer ring. Is that a wrong way to think of it?
My service layer classes can have repositories or other service classes injected. The services themselves can be injected into the presentation layer projects (e.g. a Web API or MVC Controller) and from there converted into a presentable object (DTO or ViewModel) via Automapper.
Thank you
Best Answer
What you usually call "business layer" on a layered architecture here may be called domain model but that's not the point.
You say that a ring contains another and it's a conceptual error: any outer ring communicates with its inner ring and possibly with the core. Obviously UI doesn't contain domain logic (as tests do not contain application services).
Differences with a traditional layered architecture are more fundamental than the shape you use to sketch dependencies and in this case this memoizable name (and shape) doesn't really help to grasp the fundament difference: domain model is the central absolute source of truth for the entire system. Note the breaking difference: UI will use domain model, it's not limited to Application Services ring (despite what images may mistakenly induce to think). It doesn't mean that there is a direct dependency: interfaces and IoC are in-place to provide the required abstraction and isolation, the core point isn't to isolate each ring but to isolate your domain model from any external entity.