Domain Driven Design is all about capturing the business logic into application code, no matter how complex it is. But code is not about business logic alone, there needs to be some code to take care of several other aspects like interfacing, data retrieval and persistence, communication, logging, security and much more…
To ensure that your business logic implementation becomes as maintainable as possible, it should not be influenced by any of the other code. To achieve this, you should separate it from the other aspects using a Layered Architecture.
An example of such a layered application can be found in the picture on the right. Note that layering is only a logical separation of your application and as such it is represented in the solution using solution folders which contain all the assemblies that belong to one logical layer.
The recommended approach for a layered solution is to start of with 4 different layers:
- Domain layer : Central to the solution should be the domain layer which contains all the business logic for the problem domain at hand. Ensure that this layer is not influenced by any of the other layers.
-
Resource layer : The resource layer supports the application by ensuring that the domain layer gets constructed from any resources at hand, this could be done from a local persistence store like a database or an xml file, or it could be reconstructed from a remote location like a remote service.
-
Interface layer : The interface layer takes care of displaying information from the domain model in the form requested by the consumer. This could be a windows form, a web site, a web service or a wcf data contract depending on the nature of the consumer which could be a human or another service.
-
Application layer : The application layer has the responsibility to coordinate the execution of tasks for the consumer. When the consumer is another service, this layer is rather redundant. But when a human is involved, a lot of state needs to be maintained so that the user gets presented all the reference data she can use to determine her choices before calling into the domain layer.
Special note: When you read the Domain Driven Design book, you will notice that there is no such thing as a resource layer in there. Instead it’s called the infrastructure layer which contains both resource access as other kinds of infrastructure like logging etc… But my experience has learned that you want your infrastructure code out of the way as much as possible, preferably all infrastructure should be invisible in your application using techniques like aspect oriented programming, dependency injection and such. Therefore I recommend to separate all infrastructure code outside your solution into a framework, but leave the resource access in.
Next time we will start the discussion on domain modelling and how to ensure it stays maintainable even when it becomes pretty complex.
See you next time,
Yves Goeleven
