Domain is the Heart of the software. It contains information about the domain and holds the state of business goals.

Why DDD?

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

What are the possible difficulties in application?
Experience and interest in OOP are the prerequisites for successful application of DDD. It is easy to say, but difficult to apply. It requires deliberate practice to learn how to maintain and evolve the design incrementally. It is critical to be able to explain the choice of design so let’s work together to start learning and applying DDD in our work!