6

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:

enter image description here enter image description here 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

Adam Plocher
  • 357

3 Answers3

2

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.

Adriano Repetti
  • 587
1

Business logic is actually split into two kinds in either one.

Data                                | Domain Entities      | Domain Model  
Data Business Logic                 | Repository Interface | Domain Service  
Software Environment Business Logic | Service Interface    | Application Service

Data Business Logic is the purest, most abstract, business logic. Here things like your age are derived from your birthdate and a timestamp. Here, only things that would make sense to a domain expert are allowed to exist.

Software Environment Business Logic is allowed to be aware of more than the domain. It may acknowledge the existence of the software and do some housekeeping for that. Such as express your age as a number, in a particular language, as a % of a progress bar, or as a cartoon picture with a long beard.

Onion Architecture isn't the only one to split up business rules like this. You see the same thing in Clean Architecture1:

enter image description here

candied_orange
  • 119,268
0

Business logic is the inner circle in both pictures (domain model/domain entities). This if where the meaningful processing takes place, the rest is just plumbing to make the system work.

The left picture assumes application of the repository pattern, hence the differing terminology (repository interface vs domain service). Basically the pictures are identical.

Business logic is a term used to identify a layer in so called 3-tier architecture, which is a model often used for older systems that lacked the added complexity of web applications and typically have a relational database at the bottom/core. In 3-tier you have presentation, business logic and storage. The latter layer is ignored as not interesting in the above pictures, for architectural illustration purposes it does not matter whether you are dealing with data and/or behavior and what the system ultimately does.

Martin Maat
  • 18,652