I am reading Domain-Driven Design by Evans and I am at the part discussing the layered architecture. I just realized that application and domain layers are different and should be separate. In the project I am working on, they are kind of blended and I can't tell the difference until I read the book (and I can't say it's very clear to me now), really.

My questions, since both of them concerns the logic of the application and are supposed to be clean of technical and presentation aspects, what are the advantages of drawing a boundary these two?

7 Answers 7


I recently read DDD myself. When I got to this section I was pleasantly surprised to find out I discovered the same 4-layer architecture that Evans did. As @lonelybug pointed out, the domain layer should be completely isolated from the rest of the system. However, something has to translate UI-specific values (query strings, POST data, session, etc.) into domain objects. This is where the application layer comes into play. It's job is to translate back and forth between the UI, the data layer and the domain, effectively hiding the domain from the rest of the system.

I see a lot of ASP.NET MVC applications now where almost all the logic is in the controllers. This is a failed attempt to implement the classic 3-layer architecture. Controllers are difficult to unit test because they have so many UI-specific concerns. In fact, writing a controller so that it isn't directly concerned with "Http Context" values is a serious challenge in and of itself. Ideally, the controller should be just perform translation, coordinate work and spit back the response.

It can even make sense to do basic validation in the application layer. It's okay for the domain to assume the values going into it make sense (is this a valid ID for this customer and does this string represent a date/time). However, validation involving business logic (can I reserve a plane ticket in the past?) should be reserved for the domain layer.

Martin Fowler actually comments on how flat most domain layers are these days. Even though most people don't even know what an application layer is, he finds that a lot of people make rather dumb domain objects and complex application layers that coordinate the work of the different domain objects. I'm guilty of this myself. The important thing isn't to build a layer because some book told you to. The idea is to identify responsibilities and separate our your code based on those responsibilities. In my case, the "application layer" kind of evolved naturally as I increased unit testing.

  • 23
    I don't think what you state here is correct: " However, something has to translate UI-specific values (query strings, POST data, session, etc.) into domain objects. This is where the application layer comes into play". What you are referring is in DDD's terms the "Presentation" layer. The Application Layer is supposed to deal with plumbing, concurrency and cross-cutting concerns, being just a tiny wrapper over the Domain Layer. What you are describing would correspond to a (sub) layer in the Presentation Layer. Dec 18, 2015 at 16:48
  • Agreeing with the other commentor. It sounds like App is like a Controller. This is false. Application layer does know nothing about the UI
    – IceFire
    Jun 10, 2022 at 9:13

The domain layer models the business of your application. This should be your clear interpretation of it's rules, it's component dynamics and contains it's state at any given moment.

The application layer is concerned with defining the jobs needed to be done to accomplish a certain application task. Mainly, it is responsible for mandate the necessary domain work and interacts with other (external or not) services.

For example, my financial software application has a user operation for changing the state of a model entity (entity as defined in DDD [89]):

  • "The Chief of operations can approve a financial proposal".

But, as an application process, besides all the model consequences of this operation, I have to send an internal communication to other users of the application. This kind of work is "orchestrated" in the application layer. I would not want my domain layer thinking about directing a messaging service. (and certainly this is not a presentation layer responsibility). Whatever way, one thing is for sure: I need a new layer as my domain layer is all about the core business and my presentation layer is all about interpreting user commands and presenting results.


  • Business is one of those words that frequently lead to multiple interpretations of it's meaning but for sure you can find lots of examples and talk-about in DDD;
  • DDD stands for Domain-Driven Design book by Eric Evans and number inside square brackets for page number.
  • 2
    This is probably the clearest distinction I found between Application and Domain layer over dozens of blog posts and SO topics. Thank you! Feb 21, 2023 at 10:02

Taking from Martin Fowler's patterns of enterprise design, the most common layers are:

  • Presentation - these are views, presentation templates which generate the interaction interface for your application (I am using interaction in case your application is accessed by other systems through web services or RMI so may not be a user interface). This also includes controllers which decide how actions will be executed and how.

  • Domain - this is where your business rules and logic resides, your domain models are defined etc

  • Data Source - this is the data mapping layer (ORM) and data source (database, file system etc)

How do you draw the boundaries between the three layers:

  • Application Layer and Domain Layer both comes under the scope of implementation.
  • Application Layer is acts as API.
  • Domain Layer is acts as a implementation of API, it contains business logic so it is also call Business Logic Layer.

enter image description here

  • 2
    never though of it this way....I feel enlightened
    – Nikos
    Apr 22, 2019 at 18:40
  • 1
    I like this. @Premraj could you provide reference? Jul 15, 2021 at 23:05
  • it is not like that. What is difference between API in Application layer and Front Controller?? API is presentation layer at all. App layer consist of business use cases, wheras domain layer consists of business rules.
    – zolty13
    Feb 11, 2022 at 15:33

Domain Layer should be designed as an isolation layer, which means the business logic and rules should not be affected with any codes (in Application Layer, Presentation Layer and Infrastructure Layer) changes.

Application Layer is suppose to be designed to provide some functions about what a system (application) interface (think this like an API or RESTful) can do. For example, users can log in a system, and in this application action (login), application layer codes will be the client codes for Domain Layer (or Infrastructure Layer), in which retrieves User domain object and apply this object's methods to implement the 'login' function.

Application Layer should also be designed as an isolation layer, which means the application's behaviours should not be affected with any codes (in Presentation Layer, Domain Layer and Infrastructure Layer) changes.

  • 3
    At least in literature such as Domain-Driven Design (Evans), it is acknowledged that the layers have a one-way dependency... fact is, at some point your code depends on something. UI depends on Application, but not vice-versa. Application depends on Domain, but not vice-verse. Domain on Infrastructure, not vice-versa.
    – user44798
    Jan 26, 2013 at 18:39
  • 1
    Dependency is about how your programming, the isolation layer is about how you design you system layers. One way dependency does not broke the isolation concept here, because when you programming, the top layer code should dependent on the interface of lower layer rather than the implementation classes.
    – stevesun21
    Sep 15, 2013 at 12:51
  • That's great and all on paper, but in practice, business requirements result in changes that can affect the interface of the application layer in such a way that changes bubble up through the presentation layer, and sometimes down to the storage layer. That is all I was getting at...
    – user44798
    Sep 15, 2013 at 15:40
  • Isolation layer design does not mean no changes allowed in the future. Contrary, it makes the changes much more easier -- easier to test and easier to estimate the works. Yes, a new business requirement means you may need to change from the top to the bottom, isn't it the way how you implemented the existing function before? If you can design each layer based on SOLID principles, then you may found that you can just reuse existing functions from the bottom layer.
    – stevesun21
    Jun 14, 2014 at 14:17

The main reason for these boundaries is separation of concerns. The code that accesses the data store should only have to worry about accessing the data store. It should not be responsible for enforcing rules upon the data. Additionally the UI should be responsible for updating controls in the UI, getting values from user input and translating them to something that the domain layer can use, and nothing more. It should call operations provided by the domain layer to perform any needed actions (e.g. save this file). A web service that is called should be responsible for converting from the transmission medium to something the domain layer can use, and then call the domain layer (most tools do a lot of this work for you).

This separation, when implemented properly can afford you the capability to change parts of your code without affecting others. For example, maybe the sort order of a returned collection of objects needs to change. Since you know that the layer responsible for data manipulation (usually the business logic layer) handles this stuff, you can easily identify where the code needs to be changed. As well as not having to modify how it is retrieved from the data store, or any of the applications using the domain (the UI and web service from my example above).

The ultimate goal is to make your code as easy to maintain as possible.

As a side note, some things cannot be pigeon-holed into a specific layer of the domain (e.g. logging, validation, and authorization). These items are commonly referred to as cross-cutting concerns, and in some cases can be treated as a layer that stands by itself that all the other layers can see and use.

Personally I think the layered approach is outdated, and that the service approach is better. You still have the stark line drawn in the sand as to who does what, but it doesn't force you to be as hierarchical. For example, a purchase order service, a billing service, and a shipping service, from the application perspective all of these services represent your domain, and the deferment of responsibility I described above is still valid in this context, it has just been altered such that your domain exists in multiple places, further utilizing the separation of concerns concept.

  • I have been curious about placement of authorization logic, and from what I am trying to understand, it fits into the 'application layer'. Would you mind sharing some insight as to why it might not be best to contain it within that layer of logic?
    – user44798
    Jan 26, 2013 at 18:42
  • 1
    That is the perfect type of question for this site. You should post it, so that every has a chance to answer. Jan 28, 2013 at 13:19
  • @tuespetre Could you provide a link to that post?
    – drizzie
    Apr 7, 2015 at 17:04

The point of Domain Driven Modelling is to separate the essential domain model out and have it exist without any dependencies on other layers and other application concerns.

This allows you to focus on the domain itself without distractions (such as coordinating between the UI and the persistence services).

  • Then, the data source(an ORM) is inside the domain?
    – Maykonn
    Oct 26, 2013 at 13:22
  • @Maykonn - It could be. However, an ORM is not a source of data. It is a tool between your code and the actual source of data (a relational database). How you access the data shouldn't be a concern of the domain - builders and factories can deal with that (and an ORM if you have one).
    – Oded
    Oct 26, 2013 at 19:10
  • I agree. And I was wrong about datasource and ORM. Thanks!
    – Maykonn
    Oct 27, 2013 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.