Model Driven Design Concepts

The primary design patterns used in Domain Driven Design are detailed below in this post but lets start with an overview of the concepts before we dive into the creation of Aggregate Roots and Domain Entities within a Bounded Context.

If this information is familiar to you then you can go directly to the “Domain Entities and Value Objects in Action” section.

A DDD Overview Recap

In Domain Driven Design (DDD) we strive to create a Technical Representation of the Business Domain in the code we develop.

We create these representations with a concept called Model Driven Design.

We seek to define the Business Domain using Technical Domain Models created with Model Driven Design concepts.

The technical domain is defined by the language of the business domain: The Ubiquitous Language.

This Lexicon of Terms is created from Business Jargon and capture to ensure that all members of the technology teams use and understand these terms in the same fashion.

The Language of Technology is derived from the Language of Business

… All Code, Communications and Documentation

…… Is represented by the Ubiquitous Language

Domain Models are created by organizing business functionality, with the information they generate and consume, into collections of related items.

We then “Bind” these collections and refer to them as “Bounded Contexts”.

A Bounded Context Represents a Responsibility

… Of the Business Model that is Transformed into Code

…… That can exist as an Atomic Functional Business Unit

The bounded context is a collection of State and Behavior Objects that have business Roles and Responsibilities that consume Domain Dependencies and “Bounded” by its Atomic Functionality within the Business Domain.

What is a “Bounded Context“

When defining the requirements of business there are processes that are related.

They consume common data but their responsibilities are related to a specific business requirement.

An example of a Bounded Context that most companies would have is the Customer Management context.

This image shows the bounded contexts of a typical company that provides a delivery service of manufactured products.

The Customer Management Context is bounded by the Entities and Value Objects that support its Single Responsibility to the Business Domain.

The Vendor Management Context is bounded by the Entities and Value Objects that support its Single Responsibility to the Business Domain as well.

DDD’s Model Driven Design

… Creates Boundaries around Identified Business Processes

…… That Encapsulates the Data, they Require  

The Domain Business Processes are represented as Domain Entities while the Data State Objects are represented as Value Objects.

A Bounded Context can be accessed only from a Bounded Context Root Entity called the Aggregate Root.

The Aggregate Root Behavior Class
is the only Reference that any Consuming Method
can hold to the Bounded Context

The collection of State Objects, the value objects that hold related data, can only be accessed by a call through the Aggregate Root.

This Design Access Rule Protects the Integrity
of the Data in the Value Objects

What are Domain Entities and Value Objects?

Domain Entities are Behavior Classes: Actions.
Value Objects are State Classes, Data.

Domain Entities and Value Objects are bounded together to create a  Representational Model of a Business Process referred to as a Bounded Context.

What is an Entity?

An Entity is a class that has the responsibility to manages access, data transformations and data delivery of requested information from the Value Objects contained within the Bounded Context.

Entities Have Global Identity

Entities are created, consumed and destroyed
as a unique representation within the
Domain representation of the Business Model.

What is a Value Object?

A Value Object is a class that has the responsibility of holding Data as a collections of related attributes: Properties.

Value Objects Have NO Global Identity

Value Objects are created, cloned and destroyed.
Once a Value Object is created it is never changed. 

A Value Object can be used in more than one Bounded Context. A good example of this is a list of States in the United States.

The Value Object United States would be cloned and passed to the other Aggregate Roots that requires a States list for its Aggregate Root.

If a different collection data values of a Value Object is required, a new Value Object is simply created, a list of Western United States to reduce the payload of the Value Object.

Domain Entities and Value Objects in Action

Lets see how this works using our above Domain Model.

In the Domain Model we have a Customer Management and a Vendor Management Bounded Context.

The Customer Management Bounded Context:

The Vendor Management Bounded Context:

The Aggregate Root

The two bounded contexts look quite a bit alike. The difference is in the Entities but not the Value Objects.

The same Data Transfer Objects, the DTOs, are used for both Context collection. Only the Attribute Property Data values are different: Vendor Information versus Customer Information.

In-depth Understanding of the Business Model

… Creates Reusable Representations of

…… Domain Data as Value Object Data Types

With this knowledge we can identify common Data Types (DTOs) that can support Value Objects in more than one Bounded Context.

Creating Entities using Design Patterns

The Aggregate Root is the only access to Entities within a Bounded Context.

When a Bounded Context is initially created only the Aggregate Root is required to be instantiated.

The Aggregate Root Class contains the entry point Methods for instantiation of all Entities and their related Value Objects.

Domain Entity and its Related Value Objects

… Are Instantiated as an Atomic Operation

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 Pattern – An Encapsulation of the Management of Instantiated Domain Objects and their Persistence

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

4. Strategy Pattern – The pattern the Domain Service uses to identify the Domain Entity that the Factory will instantiate  

Instantiate A Domain Entity from the Aggregate Root

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.

Concluding Thoughts

Bounded Contexts and the design patterns support the Object Oriented Programming concepts of Loose Coupling and High Cohesion.

The organization of the business processes in bounded structures allows the Designer to create performance optimization strategies that are targeted for specific business functionality.

Data Structures can be designed for “Consistency”: Fast Changing Data or for “Performance”: Slow Changing Data.

The architecture presented in this post encapsulates those responsibilities to the design patterns best suited for object management, instantiation and delivery to the Domain Bounded Context.

Changes to Business Rules, can be easily implemented due to the High Cohesion of the Service Locator design.

Changes to the Entity and Value Objects can be effectively be managed due to the Loose Coupling of the instantiation for the persistence models.

The Data Objects, the DTOs, can be organized for reuse based on segregated responsibilities that span across multiple Bounded Contexts.

In future posts we will explore how relationships between Bounded Contexts can be managed using the Domain Driven Design concept of Context Maps.

… The Human Mind Can Only Conceptualized

…… Small Amounts of Information at a Time

… Bounded Contexts and Context Maps

…… Creates Compartmentalized Organization

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