Domain Driven Design
Domain-Driven Design is a collection of principles and patterns for mapping business domain concepts into software artifacts.
- This mapping provides an easy understanding of the business requirements, data entities, and process models.
- The derived model is modular, extensible, and easy to maintain as the design reflects the business model.
- It improves the reusability and testability of the business domain objects.
Characteristics of a Rich Domain Model
- The domain model should focus on a specific business operational domain. It should align with the business model, strategies, and business processes.
- It should be isolated from other domains in the business as well as other layers in the application architecture.
- It should be reusable to avoid any duplicate models and implementations of the same core business domain elements.
- The model should be designed loosely coupled with other layers in the application, meaning no dependencies on the layers on either side of domain layer.
- It should be an abstract and cleanly separated layer enabling easier maintenance, testing, and versioning. The domain classes should be unit testable outside the container.
- The domain model should be independent of persistence implementation details.
Building Blocks of Domain-Driven Design
- Aggregates
- Entity
- Value Object
- Repositories
- Services
- Factories
Architectural, Design & Implementation Aspects
- Business Rules
- Persistence
- Caching
- Transaction Management
- Security
- Code Generation
- Test Driven Development
- Refactoring
Domain Driven Development Phases
- Model the Domain
- Design
- Development
- Unit and Integration Testing
- Refine & Refactor the Domain Model and Repeat