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 ?

Amazonas

A good article on this subject – Cactus

Answer 1

Totally agree with Hippoom's answer. It is perfect to start from there.

Now,

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.

Yes, decision about layers in an application depends upon many factors in a particular scenario. It is like how a universities divide their programs and make curriculum. It depend upon the capacity/diversity they want to serve, the need in hand and the purpose of university. It is very different in details (naming and partitions) across the globe but the core and intent is always same.

In the same way, Layers in an application depends upon the need and scope. Sometime architects used to define the name of layers as per their philosophy and convention followed in the organization. So sometime the intent and name may differ to some extent. But the code idea of having salable, maintainable and fulfilling the functional and non-functional requirements in hand, remains always same.

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 ?

Hippoom did it very well already and he described the intent in shot also.
Standard Layers are described here: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
As I already mentioned layers may differ as per applications need.

Hope it would help you. Thanks.

Included details as per David's first comment below:

Application services implement the use cases and make calls to the Domain Services and Domain Entities and Infrastructure Services in order to get the job done. It provides interfaces to outside world (mainly UI layer projects) to accomplish certain functionalities. For example, UserService is an application service. UserService may provide functionalities to check for authentication for user and authorization for particular resource, change privilege for a user by admin, ban the user etc. To accomplish these use cases, it would use UserRepository and UserEntity from lower layers.

Domain services are application-agnostic; they provide a means to ensure the integrity of the domain model by encapsulating CRUD (Create, Read, Update, Delete) operations and data access. They usually have Repositories of Domain objects and UoW implementation etc in Onion Architecture.

Habitable

I read the last article you linked It seems to have plenty similarities with Hippoom's answer. But I did not understand why some of the layer had "Services" in their name. Domain services, Application services. Would you like to explain the meaning to me, please ? – Amazonas

Domain services and Application services on that link stand for the same what Domain and Application layer does in Hippoom's answer. It is just naming conversion difference. Application services and Domain service details I have included at bottom of my answer because of limit of words in comment here. Thanks. – Habitable

Thank you for the answer. I guess I have three last questions. What is the infrastructure layer for, what should it contain ? Where goes the presentation logic (is it the UI/Presentation/Interfaces Layer)? – Amazonas

Most welcome ! Infrastructure layers have infrastructural concerns such as the interacting with a database (database setting etc. and obviously it would be used in other layer having logic doing CRUD on domain entities), communicating across a network (if external web service like paypal or any FTP call etc), sending an email by SMTP etc.. The Presentation Logic goes to UI/Presentation/Interfaces Layer. UI layers concern about the ways you want to show data, It may have client side validations and animation etc.. if you are using those in UI. Hope it would help. Thanks. – Habitable

@PraveenPrajapati So in general "UI", "Presentation" and "Interfaces" are the same here?? And Infrastructure is basically the same as Data access layer, right? – Barrick

@Barrick ...Not at all. I am wondering how did you deduce it ? – Habitable

@PraveenPrajapati Hmmm... I deduced it from these quotes The Presentation Logic goes to UI/Presentation/Interfaces Layer and Infrastructure layers have infrastructural concerns such as the interacting with a database so I have got it wrong? – Barrick

Thanks. I got the idea. I understand it is because there are different kind of applications and they use different naming as per their suitability. To give an example with respect to Infrastructure layer...it can be huge having Repositories, DB, Web service, Logging, Monitoring, Utilities etc., so DB can be just a part of it (not DAL = Infrastructure). Same applies to presentation logic...sometime big codebase having XAML, MVVM pattern and PRISM (in WPF application) called as presentation layer and for some app there is no UI are all like web services. So UI may be a part of presentation. :-) – Habitable

Answer 2

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

In short:

1. Interfaces 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.

Sarcocarp

So, to quickly summarize, domain layer represents an abstraction of the domain, application layer represents the extra non-native features, functionalities atop of the domain we provide, and interfaces are all the ui projects (wpf, silverlight, asp.net web forms/mvc) ? I begin to grasp the concept, but I am still uneasy about the infrastructure layer. Basically, it is a huge "utilities/put anything you want/put the implementations of the abstractions in Int./A/D layers" layer ? Whenever there is a tight coupling in Int./A/D layer, you just interface it and implement in Infrastructure ? – Amazonas