A knowledge rich domain essentially means that domain objects in the system contain related behavior. Many projects follow the anemic domain pattern in which their domain objects contain data with getters and setter methods but do not contain any behavior methods. The behaviors are implemented with "managers" or "controllers." DDD advocates that behaviors related to an object should be contained in that object. Several added benefits are gained from a knowledge rich domain. Behavior logic is contained in one object, often reducing duplicated code resulting in a gain in reuse. Objects are more encapsulated and follow the "tell don't ask" principle. Systems with knowledge rich domains are often more understandable and intuitive as an object manages its own data and its related behaviors can be found with that object, resulting in better maintenance.
Layered Architecture is a technique in designing software in order to separate concerns of a system, reduce coupling, and to isolate the domain layer of a system. An enterprise software system indelibly has several common concerns. A user interface accepts actions from a user, data must be saved to a database, transactions must be managed to maintain integrity of data, and business logic must be implemented. The question arises of “where do all these concerns get implemented within a system.” If these concerns are flattened into the presentation layer, this can lead to brittle software where one change could trickle to several areas and possibly unrelated areas of a system, thus making maintenance a headache. Changes become unintuitive to implement and scattered across a system. Layered architecture is fundamental concept not original to domain-Driven design, but nicely complements the idea of separating the domain layer. Evans concisely states the essence of the pattern:
Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work.
The typical breakdown of a system with layered architecture has the following layers:
- User Interface (Presentation Layer)
- Application Layer
- Domain Layer
- Infrastructure and Technical Services Layer (Persistence Layer)