What is Domain Driven Design (DDD)?

The simple Domain Driven Design definition:

A Collection of Principles and Patterns

… Used to Transform the Business Domain

…… Into Technology Domain Models as Software Abstractions

The key take away from that definition is “Business Domain” as “Technology Software Abstractions“.

Using the Software Design Abstraction the Technology Domain Model becomes the resulting Developed Code Base during the Agile Sprint  Iterations.

The Domain Model Is the Code

… The Code Is the Domain Model

The Domain Model is not an abstract concept, a vague idea, a set of design diagrams or collections of technical drawings.

It is quite literally the Developed Code created from a representation, the Software Design Abstraction, of the Client’s Business Domain under review: The Client’s “Problem Domain”.

The Client’s Business Domain
is what Distinguished the
Client’s Company from its Competitors

We do represent the Client’s Problem Domain as DDD Domain Models in diagrams, drawings and text documents but:

The Domain Models encapsulate the daily complex business logic that drives the Enterprise by closing the ever-growing gap between the Realities of the Business Activities and the deployed code created to support the Drivers of Business Success.

The Ubiquitous Language in DDD

 The Ubiquitous Language is the Lexicon of Terms that define the problem domain.

This dictionary creates a common language for all of the Teams to communicate with each other.

This “Language of the Business Domain” helps prevent gross misunderstandings of the “Technology Domain Models“.

Domain Models Abstractions, all engagement documentation and the entire Developed Code Base must comply with the Ubiquitous Language’s Lexicon of Terms at all times during the Software Development Life Cycle (SDLC).

Changes in the Domain’s Ubiquitous Language

… Triggers a Refactoring Change 

…… To All Documentation and to the Relevant Code Base

This discipline should be enforced by the Sprint Code Review Team to guarantee a continuous common understanding of the Domain Models throughout the deployed solution’s lifetime.

In Conclusion

A clear understand of Domain Driven Design requires a clarity of the Principles and Patterns that will be discussed in other modules in the series.

This post’s success criteria is to present to the viewer with a clear definition for understanding of the primary concept of DDD: Creating DDD Domain Models that represent the Client’s Business Model. 

The “How” of DDD Domain Models will become clear with the understanding of DDD Patterns such as the “Bounded Context” that represents directly a Business Model as a Domain Model Representation.

Wisdom Pearl # 123 – Organized Your Creations

A Place for Everything

… And Everything in its Place

…… Organize Your Creations By Their Behaviors and Responsibilities