I have trouble drawing a clear line between Presentation and Application layer in Domain Driven Design.
Where should Controllers, Views, Layouts, Javascript and CSS files go?
Is it in the Application or the Presentation layer?
And if they go all together in the same layer, what contains the other one? Is it empty?
Just because someone created and named “Application Layer” and “Presentation Layer” doesn’t mean your application should have them.
You should create layers AFTER you created substantial amount of code which you grouped together and want to name this group for sake of communication between developers and clarity of code.
From point of DDD. Application Layer is everything that is not Domain layer. Which includes application logic, presentation and application services.
3
There is a big difference between the application layer and the presentation layer from a DDD view point.
Although DDD centers around how to model the domain using the DDD building blocks and concepts such as bounded contexts, Ubiquitous language and so, it is still vital to clearly identify and separate the various layers in your app.
The architecture plays a big role in implementing a successful DDD app. A famous architecture that gained a lot of hype lately is the onion architecture:
In this design the UI/Presentation layer and the application layer are clearly separated. Merging the 2 together introduces tight coupling between 2 layers that have clear separate concerns and responsibilities.
The Presentation layer should only house presentation logic. Avoid Smart UIs that know too much. This mainly houses the MVC’s Controllers and views in addition to CSS, JS, templates, forms and everything that relates to response and request objects.
The actions issued through presentation are delegated to the application layer through commands. The application layer contains the application logic. It normally maps to a use case. It contains WHAT the system should do to satisfy a use case. A typical application service will ask a repository to return an aggregate then invoke an action on that aggregate.
Have a look at the sample project from Vaughn Vernon’s IDDD
2
Domain Driven Design has nothing to do with either Presentation layer or Application layer. DDD is a methodology whose main focus is on the Domain layer. That is, DDD does not impose any constraints regarding any other layer except for the Domain layer and Your question as well could be asked in the context of any other methodology.
That being said, it’s very common to use a four-layer architecture for DDD applications. Here’s an example of one such application showing the layers and their intended use: DDDSample Architecture. So, if you choose to use this architecture your views and layouts would go to the Interfaces layer and the controllers, if interface-independent, would go to the Application layer.
You might as well choose any other kind of architecture, as I’ve said DDD does not impose constraints. There are many MVC frameworks out there that have different structures and yet could also be used for DDD applications. Then, of course, you would place Your views and layouts accordingly.