Semantic Design Series: Design Patterns

Print Friendly, PDF & Email

Featured Domain Design Patterns

Design Patterns in Domain Driven Design

The Domain Model objects, such as the elements of a Bounded Context, must manage the objects life cycle from instantiation to destruction.

How an object is created, delivered, consumed, persisted and destroyed must be managed as a sustainable model.

A collection of Domain Design Patterns are used to manage all of the Aggregate Root Bounded Contexts that are represented within the Domain Context Map.

The Domain Driven Design Patterns

The primary design patterns for managing Bounded Context Entities are:

  1.  The Factory Pattern – An Encapsulation of the Processes for Domain Object Instantiations

  2. The Repository Cache Pattern – An Encapsulation of the Management of Instantiated Domain Objects and their Persistence

  3. Services Pattern – An Encapsulation of the Strategies for Delivering Complex Object Collections to a Bounded Context

DDD Aggregate Root

Instantiate A Domain Entity from the Aggregate Root

+The Domain Entity Instantiation Process
  1. The Aggregate Root Create Entity Method calls the Domain Service to return selected Domain Entity from the Domain Repository
  2. Call Domain Service queries the Domain Repository for the requested Bounded Context Domain Entity
    1. The Domain Repository checks for existence of Domain Entity and its related Value Objects in:
      1. The Domain Cache Persistent Storage
      2. The Infrastructure Layer Persistence Storage
        1. Database Persistence
        2. File Persistence
      3. Return Bounded Context objects if Exists
    2. If not found in a Persisted State
      1. Call Domain Factory to return Bounded Context Domain Entity Object Collection
        1. Use a Strategy Pattern to identify the Domain Entity for the Domain Factory to create the Domain Entity and its Aggregate Root Objects
        2. Instantiate Domain Entity
        3. Instantiate all Aggregate Root Objects
      2. Return Bounded Context Entity and its Value Objects to the Domain Repository
  3. The Domain Repository uses a Defined Entity Persistence Rule to persist the Domain Entity Object Collection
    1. Cache Persistence
    2. Infrastructure Database Persistence
    3. Infrastructure File Persistence 
  4. The Domain Services receives the Domain Bounded Context Domain Entity and its Value Objects
    1. The collection is returned to the Domain Bounded Context’s Aggregate Root
    2. The Calling Class Method can now consume the Domain Entity’s Value Objects Immutable Data

In Conclusion 

The creation of a Domain Entity and its Value Objects should be an atomic operation.

All the Value Objects are required to be initiated and ready for consumption

This lifetime management of the collection of objects should be managed by the Domain Factory using an Inversion of Control (IOC) container.

Wisdom Pearl # 137 – The Primary Technical Imperative

The Primary Technical Imperative in Software Development

… Is to Manage Software Complexity

…… Always be able to Justify Your Designs Complexity

The following two tabs change content below.
Brad Huett
My Twitter profile

Brad Huett

I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Brad Huett
My Twitter profile

Latest posts by Brad Huett (see all)

If you think this post was worth your time: Like It Please

%d bloggers like this: