Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

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

a) 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.

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

c) 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:

a) Do not put presentation specific logic within your models or domain objects

b) Do not put logic within your pages and controllers, i.e., logic to save objects to the database, create database connections etc, which will make your presentation layer brittle and difficult to test

c) Use an ORM which enables you to decouple your datasource access and actions from the model

d) Follow the thin controller - fat model paradigm, controllers are for controlling the process of execution not carrying it out, more at http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ and http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model model, view and controller,

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
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. –  tuespetre Jan 26 '13 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. –  lonelybug Sep 15 '13 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... –  tuespetre Sep 15 '13 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. –  lonelybug Jun 14 at 14:17

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).

share|improve this answer
    
Then, the data source(an ORM) is inside the domain? –  Maykonn Oct 26 '13 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 '13 at 19:10
    
I agree. And I was wrong about datasource and ORM. Thanks! –  Maykonn Oct 27 '13 at 14:18

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.

share|improve this answer
    
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? –  tuespetre Jan 26 '13 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. –  Charles Lambert Jan 28 '13 at 13:19
    
Thank you, I will do that! –  tuespetre Jan 28 '13 at 19:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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