How to structure a Domain Driven Design in an Onion Architecture?

Question

I am studying Domain Driven Design and was introduced to the concept of Onion Architecture, which uses the terms of Core, Domain, API, and Infrastructure.

I am from Java background and am familiar with and typical project structure (legacy MVC pattern) configuration, model (both value and entity), repository, service, controller, and views.

If I want to build a project as per Onion Architecture, how am I supposed to fit the related components of my structure to Core, Domain, API, and Infrastructure? The API part is understandable but I am confused with Core and Infrastructure.

Say for example all Business logic related to domain goes inside domain including Entity value Objects repository etc.

What is then the Core and what is in the Infrastructure? I can't understand the explanation bellow

Core is the building blocks not specific to any domain or technology, containing generic building blocks like lists, case classes and actors. It will never include technological concepts, e.g. REST or databases.

Infrastructure is the outermost layer containing adapters for various technologies such as databases, user interface and external services. It has access all the inner layers but most operations should go through the API, one exception being domain interfaces with infrastructure implementations.

Can you help me to get a clear understanding of the concepts about these two layers?

Answer 1

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.

Answer 2

For those who have the same question and still have a little confusion, This may help them.

1.Infrastructure: As the definition says one part of Infrastructure is a bridge between domain classes( consists of business-related logic) and Database relationship. and if you are using ORM (Like Hibernate Spring data e.t.c)then the implementation is already there. the whole conception is about decoupling.

2.Core: Thanks to the accepted answer it has already described core part beautifully. I would prefer to put Value Objects inside the core, Being said that

Core is the building blocks not specific to any domain or technology, containing generic building blocks like lists, case classes, and actors.

it is pointing towards value Objects and may be custom types.