Domain is the Heart of the software. It contains information about the domain and holds the state of business goals.
Normally, I use functional approach to minimize the structure complexity in web development and duplicate a great amount of code to reduce the dependencies between pages and modules. Our system design fits well in the beginning as I aim for a quick fix.
However, the maintenance cost becomes increasingly higher with the growing features and duplications. I first heard about Domain- Driven Design (DDD) while learning Test-Driven Development (TDD). It showed me a clear vision on how to apply object orientation in a product.The emphasis placed on the business domain leads us to separate the business logic, the real point of the system, from the technology hype.
Agile methods have their own problems and limitations as they advocate simplicity, but everybody has their own view of what that means. Also, continuous refactoring done by developers without solid design principles will produce code that is hard to understand or change. DDD combines design and development practices, demonstrating how to model and implement the complex problems in the domain in a sustainable way.
What is DDD?
There are six building blocks in DDD:
1. Entity: An object that has an identity.
2. Value Object: An object that contains attributes but has no conceptual identity. They should be treated as immutable.
3. Aggregation: A collection of objects that are bound together by a root entity.
4. Domain Service: When an operation does not conceptually belong to any object.
5. Repository: Methods for retrieving domain objects.
6. Factory: Methods for creating domain objects.
DDD uses a four-layer approach. The User Interface and Application layers are purposefully left thin. All the business logic is stored in the Domain layer, forcing us to ponder what belongs or is excluded in domain logic.
How to implement DDD?
Honestly, I only take about 20% of the principles from the original DDD books written by Eric Evans. We adopt DDD concept as a guideline to apply Object-orienting programming (OOP) and SOLID principles. Design and implementation workflow:
1. Draw sequence diagram for the user story.
2. Identify the domain objects and the interface between different components:
- Interface for repositories
- Domain/POCO objects
- Interface for external API services
- API request and response objects
- Application service to coordinate the activities
- Model view objects for input and output
3. Create the skeleton of the system covered by system integration test.
4. List down the sub-tasks to complete the implementation for all domain objects and services functions.
5. Refactoring the application service to extract the class as it grows bigger:
- Extract domain service for business rule validation
- Extract factory for complex object creation