What are the typical layers in an onion architecture?

Question

I am currently studying the domain driven design, and try to apply it for a WPF project. I watched some tutorial videos, and read many articles, like :

• Onion archicecture dependencies in the same layer: Infrastructure and Web communicating
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• Domain Driven Design: Domain Service, Application Service

I understood the focus on interfaces and inversion of control. I read there were some recurrent layer names (domain/core for the representation of the sphere of knowledge, infrastructures for persistance, application for ... i don't understand), but they change, depending of articles I read. Some even do not appear.

Would it be possible to have an list of all layers that, in theory, are required in an onion architecture to face all needs and problems, with their intent (what kind of code do they contain, what kind of need do they try to fulfill, which layer do they need to reference), please ?

Answer 1

Just some personal experience, I use this architecture mentioned in Eric Even's DDD book:

In short:

1) Interfaces is consist of components that are responsible for interacting with user(a real endpoint user or a remote machine), web mvc controller, web view object, remote facade for example.

2) Application defines what features your system provide. I think it's highly coupled with the Interfaces layer. If you define a method in Application, often you need to add a Interfaces class/method as well. But several Interfaces class/method may depends on the same Application object, you provide both a web ui and a web service for place order, for example.

3) Domain, the most stable part of your system. For example, in language context, word/sentence are Domain objects that have their own meaning, I oganized them to form this answer. So you could consider me as an Application object although not a good one 'cause I don't speak fluent English :P

4) Infrstructure, actually I don't think this is a layer, it implements all the above three. For example, you have an interface OrderRepository in your domain layer and you could implement it using some orm framework (persistence infrastructure). Most of my infrastructure objects are adapters (implements an interface in Application/Domain/Interfaces layer and adapt to external components like database, messaging provider, mail server and so on).

Hope this helps.

Update for infrastructure intent:

This is one of our project's package view.

There are some adapters in the infrastructure layer:

1.infrastructure.channel.XXX each package contains several adapters to a particular online payment provider.

2.infrastructure.payment contains adapters to a payment system of our organization but it is in another bounded context. We use MakePaymentService (a domain service) to decouple the payment system from other part of this system.

3.infrastructure.messaging contains adapters to messaging provider, we provide a jms implement for PaymentWasMadeNotifier (an application service)

4.infrastructure.persistence contains adapters to database, we provide a iBATIS(a orm framework in Java) for Domain Repositories.

These above adapters all implements some interface s in Application/Domain layers. Below is some "service", but they are generic:

5.infrastructure.mail

6.infrastructure.logging

7.infrastructure.security

These package above expose some interface and implementations. For example, we provide a MailManager interface, it's agnositic to particular features. The subject, content is up to the application layer/domain layer. We provide an implementation using javamail in the same package.

public interface MailManager {
void send(String subject, String content);
}

8.infrastructure.time this one is special, we have some cron job in this system, so we introduce a Clock to decouple the time from job setting and therefore its friendly to tests (Just imagine that we have a job, it should be launched at 25th, every month, we can test the job by setting current time to 25th, even if it's 1st today). We provide an implementation in persistence package(For some reasons, we need to use database' time in production)

 public interface Clock {    
    Date now();
 }

So my understanding is: infrastructure provides service/implementations to your other three layers, but they are technology specific. For example, Subject, content, from, to, cc are domain models in mailing context, but they are infrastructures in your domain context. The infrastructure layer separate them for you.