Model Driven Design Concepts

In Domain Driven Design (DDD) we strive to create a Technical Representation of the Business Domain in the Technology Domain 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.

Concluding Thoughts

Model Driven Design uses a collection of concepts that creates the ability to represent the Business Domain into a highly scalable Technology Representation of that Business Domain.

With the use of a Layered Architecture to isolate layers, constructed with terms from the Ubiquitous Language, we create a highly cohesive model within the Technology Domain.

We can express the Domain Models using globally identifiable Entities that consume immutable data structures as its Value Objects that do not have a global identity.

Collections of these Domain Entities can be organized in stand-alone structures called “Bounded Contexts” that a consuming Client can only hold a reference to the Aggregates “Aggregate Root” of the Bounded Context.

These data structures can be shared as “Cloned Data Structures” for use in other Bounded Contexts when the immutable data are equal for the shared “Bounded Context”.

Best practice design patterns such as Domain Services, Domain Factories and Persistence Repositories support code reuse and increased performance through responsibility encapsulation.

State change can be expressed using run-time Events.

The Domain Models can subscribe to global events that destroy and recreate Value Objects.

Events can execute Entities Methods through the Domain Model’s Aggregate Root.

A “Domain Context Map” defines the relationships between the various Domain Bounded Contexts.

The Understanding of the Business Domain
is Represented by the Context Map
and Defined by the Aggregate Roots

Text items above highlighted represent the elements on the
Model Driven Design Object Map above 

Wisdom Pearl # 116 – The Modern Developer’s Mantra

I will Practice My Developing Art First

… And Practice My Sciences Second