Phases of Domain Driven Design

• Strategic Phase: This helps in understanding the domain and identifying the bounded contexts. In DDD, technical team with the help of domain experts first develop the understanding of the core domain and then identify the sub-domains along with their relationship to each other. Once the relationship is defined and understood by the team, the boundaries can be defined where sub-domains with-in the same boundary will going to share the same domain models and ubiquitous language.
  
  Traditional approach or event storming can be used to identifying the bounded contexts.


• Tactical Phase: This phase provides a set of design patterns to define domain model with more precision for each identified bounded context. First, identify the ubiquitous language for a bound context and then start defining the domain model. Let us understand entities, value objects, aggregates, aggregate root, services and events.
  • Entity:
    • Entity is an object which can be identify with an unique key/Id and persists over time like in a banking application, customers and accounts would be entities.
    • Entity ID may span in multiple bound context. Consider bank account and Govt Aadhar Card to understand how Entity and its ID behave in different bound contexts.
    • The attributes of an Entity may change over the time like in Person entity, name and address of the person can change at any time.
    • An entity can hold reference to other entities.
  • Value Object:
    • An object which are immutable and don’t need unique Id. For example, color, date time, address, etc.
      

      “Many objects do not have conceptual identity. These objects describe certain characteristics of a thing.”…… as mentioned by Eric Evans for Value Objects.

  • Aggregate and Aggregate Root:
    • Aggregate is to maintain the consistency around one or more entities. In simple words, aggregate is a group of one or more entities and their behaviors where there is an inter-dependencies between entities and transaction consistency is required.
    • Exactly one entity in an aggregate is the aggregate root and always remember that any communication will be done via the root entity only.
    • In DDD, the main responsibility of an aggregate is to enforce the invariant (business rules/validation) for all the entities with in an aggregate root.
  • Domain and Application Services:

    In Domain Driven Design terminology, a service is an object that implements some logic without holding any state. Domain Service can encapsulate domain logic while Application service can provide technical functionality for examples sending an email or SMS.

  • Integration and Domain Events:
    • Semantically, there is no difference in Domain and Integration events, both notifies that something happened in the domain.
    • The purpose of the integration events to notify the other microservices, bound contexts, sub-systems or external applications that something happened successfully in a particular bound-context or sub-domain.
    • The side effects of domain events handled within the same bounded context while the side effects of integration events handled by other microservices or others sub-system or bounded contexts or external systems.
    • Integration events must be based on asynchronous communication so that other microservices or bounded contexts or external systems can handle other required side effects.