This time, let explore the concepts of a layered architecture, as proposed by Eric Evans in its classic book Domain-Driven Design, Tackling Complexity in the Heart of Software. In the chapter four of the book, Evans presents this diagram:
For a shipping application to support the simple user act of selecting a cargo’s destination from a list of cities, there must be program code that (1) draws a widget on the screen, (2) queries the database for all the possible cities, (3) interprets the user’s input and validates it, (4) associates the selected city with the cargo, and (5) commits the change to the database. All of this code is part of the same program, but only a little of it is related to the business of shipping.
He proposes that the domain model resides in a layer, the Domain Layer. In this way, the domain model is protected from technicalities as concrete persistence implementation, and presentation duties. I like to say that the domain is as an organism, that receives stimula, actions from the outside, and reacts to such commands. The domain should run without detailed knowledge of the rest of the application. Serialization between physical tiers, presentation details and database access, should be clearly separated from the domain implementation.
The layers could be described as:
UI (User Interface): the easiest to understand, this layer is the responsible of displaying information to the user, and accept new data. It could be implemented for web, desktop, or any presentation technology, present or future. For example, it could be a voice application, that interacts with the user via a phone. The acid test for our design is that a radical change in user interface should have minimal (or controled, at least) impact in the rest of the system.
Application Layer: it’s in charge of coordinating the actions to be performed on the domain. There are no business rules or domain knowledge here. No business state resides in this layer. It delegates all domain actions to the domain. It could coordinate many actions (possibly in many domains). It could prepare the infrastructure to be ready to work with the domain for an specific action (for example, preparing transaction scopes).
Domain Layer: In this layer resides the heart of software, according to Evans. Business rules and logic lives inside this layer. Business entity state and behavior is defined and used here. Communication with other systems, persistence details, are forwarded to the infrastruture layer. Evans discuss the patterns he uses in this layer, as Entities, Value Objects, Services, Repositories and Factories. We would explore the patterns and implementations in future posts.
Infrastructure Layer: God and devil are in the details, and in the infrastructure layer. Its main responsability is the persistence of the business state, most frequently, using a relational database.
My idea is to take an example (possibly a domain from Jimmy Nilsson), and develop it using these ideas, showing concrete code in Java and .NET. At some point, I will discuss about code generation from an abstract model, but it will not be the focus of these posts.
Domain-Driven Design, Tackling Complexity in the Heart of Software, by Eric Evans.
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, by Jimmy Nilsson
.NET Domain-Driven Design with C#, Problem, Design, Solution, by Tim McCarthy. (There is a section in Tim’s blog dedicated to this book).
You can download freely
Angel “Java” Lopez