Onion Architecture – Application and Domain Services Explained

Ideally, you have separate domain models and data transfer objects (DTO). The domain model is a model per layer or domain. For example, the UI layer and the business logic layer should have their own domain objects.

You use DTO's to pass "data" between the layers.

[UI Layer] <- UserDto -> [Business logic layer]

The act of converting the domain objects to DTO's and back again on the other side is generally called "object mapping". Libraries like AutoMapper are used to simplify the process.

Overview

Let's step back a little, and look at the original Onion Architecture proposed by Jeffrey Palermo.

The outside skin is the interface to the external world: the user interface, the test suite (the idea is to promote TDD alike systematic tests for everything inside), and the infrastructure.

Then you dig deeper inside towards the core to find application services, domain services, and domain objects (in the core of the core).

Infrastructure

Infrastructure has a different meaning here than elsewhere. It is in fact the interface to the outside world, and especially to services sourced outside, such as database management systems or external web-services, local or cloud storage service, etc.

The term "adapter" is directly inspired from Cockburn's hexagonal architecture: the idea is that the inner side of the adapter remains unchanged, but the external part can vary. Hence, one day you work with an Oracle adapter connecting your application services to an Oracle DBMS, the day after, you can develop a MongoDB adapter to switch to Mongo as new persistence layer.

So the platform and OS specific stuffs should be in the infrastructure layer. If you follow this logic, everything which is in the inner circles is platform neutral ("technology neutral" may be misleading).

Towards the core

Here you have an example of mapping in the original onion architecture:

• Domain objects (entities, value objects, aggregates) are in the core
• Around domain, you'll have domain services (e.g. repositories, services, etc...)
• And still around you have the application services, i.e. the services to which user interface or other interfaces are connected.

However, Wade Waldron's variant is a little different for the inner part:

• The core is made of building application blocks which are domain independent, and used by the domain. It's like those offered by a standard library. Personally, I have the feeling that this is not a good idea: those basic constructs do not fit into this structure. They are indeed used by the next ring, but they may also used by any other ring, diretly, even without going through the domain. In fact the core should be orthogonal to this architectureit. In other words, you may use a list anywhere in the architecture, without having to go through the successive rings to the core.
• Ok, the domain is clear, but he puts there everything which is domain related, including: entities, value objects, aggregates, and also repositories, factories and domain services. So he regroups domain objects and domain services of the original model.
• Ok, API is obvious: it' corresponds to the application services in the original architecture, those which are not accessible directly, but via the outside ring.

This video shall explain in detail and with example Waldron's variant of the Onion architecture.