Domain Driven

Design
Words of Wisdom
A Big Ball of Mud is a haphazardly structured,
sprawling, sloppy, duct-tape-and baling-wire,
spaghetti-code jungle.
- Brian Foote and Joseph Yoder
It doesnt take a lot of skill to get a program to
work. The skill comes in when you have to keep
it working.

- Robert C. Martin @unclebobmartin

Traditional Approach
Usually our Applications are developed with Data Driven
approach, which is basically of CRUD approach. That is Create
Retrieve Update and Delete.

Even most those fancy Applications of OOP are actually built with
the same mindset. And then we see people complaining about the
programming is hard, and Entity is huge and scary to modify.

CRUD approach is all about get some data from forms (UI), do
minor processing and save it to Database again.

A simple Data Drive application which serves little more than as

an UI for the Database.

You only need to create the required data structures (Data models)
and that is it.
Need of DDD
Data Driven Design Approach works on the long term, only if the
Application stays true to its nature. i.e. it changes very little and
changes are still about data moved from form to db and back.

If the Application changes to model business concepts or flow,

then you are following wrong approach.

It is not about developing a quick and dirty application, it is

about developing a complex system which will very likely to
evolve over time.

This is where Domain Driven Design comes in to play.

Need of DDD
The critical complexity of most software projects is in
understanding the Domain itself. DDD Focus on the
Domain and is based on modelling behaviour and more
exactly, with modelling some real life business aspects
into code. Its not about getting some data to be
persisted, its about recodesenting virtually the
business flow.
Modelling and design take extra time, but they pay off
in the long run, in fact Modelling and design are often
the quickest path to reach the actual Goal. Take your
time to understand the domain and dont rush it, is the
basic philosophy of DDD
 Need of DDD
Domain Driven Design is evolving a software system that closely aligns to
business requirements. DDD address the analysis and design of software
that relies on complex Domain specific knowledge.

1. Domain-Driven Design is a development philosophy that values teams

understanding the domain they are writing software for above anything
else.
2. It is a collaboration philosophy focused on delivery with
communication playing a central role.
3. The creation of a shared language is vital for knowledge sharing and
domain understanding by the development team and business experts.
4. Domain-Driven Design is more problem solving through collaboration
than code patterns language.
5. Learning and creating a language to communicate about the problem
domain is the process of Domain-Driven Design, code is the artifact.
 Domain

Domain: A Sphere of Knowledge, Influence or Activity of

Core Business Functionality, Domain is represented by the
Ubiquitious Language.
Ubiquitious Language

Ubiquitious Language:

A Major reason for failure of software projects is

a failure of people, the failure to communicate.

The Ubiquitious Language is a shared language

between the business and the development
teams. The UL comes from the business, and is
enriched by development teams.
Ubiquitious Language
 Domain Vision Statement
The Domain Vision Statement is a shared understanding of what
it is you are actually trying to create. It should be in brief, written
in clear English and understood by Business and Tech people
alike in Ubiquitous Language. It should be Factual, realistic,
honest.
It should avoid Technical and Implementation details. It should
avoid superlatives and marketing speak. It is importantly not
focused on the How, but what and why.
Domain Experts are experts who have Deep knowledge of the
subject Domain. They are experts on their part of the Business,
not just users of the System.
They are accessible and primary point of contact for the
development teams. Development should be in iterative
process.
 Domain Model
In DDD we need to create Domain Model First. The
Domain Model is about our organised and structured
knowledge of the problem.
The Domain Model should represent the vocabulary
and key concepts of the problem domain and it
should identify the relationships among all of the
entities within the scope of the domain.
It is extremely important that all stakeholders of the
project contribute to the Domain Model so that
everyone understands the key concepts and
definitions of the vocabulary of the project and how
the problem is being tackled and solved.
 Domain Model

The Domain Model itself could be a diagram or

written documentation of the problem. Normally it is
a Story with clear to reveal the Intention but not
implementation.

The important thing is, the Domain Model should be

accessible and understandable by everyone who is
involved with the project.
Domain Model
1. A model is the mental representation and not
developed in a one-shot deal.
2. Represents real-world concepts, not software components.
It gives a conceptual framework of the things in the problem
space.
3. Represents relationships between Entities and Values
Objects with in the Domain.
4. Models are not a design Artifact and ignores persistence.
5. The model emerges out of multiple iterations of refactoring,
discussion and knowledge evolution.
6. Start with an initial model that is a best guess based on a
discussion with domain experts.
7. Evolve the model throughout the lifetime of the project.
DDD - ENTITY

Entity:
An Object defined primarily by its Identity and have state
is called an ENTITY.
ENTITIES have life cycles that can change their form and
content.
ENTITIES are things with in the model and Uniquely
identifiable.
DDD Value Objects

Value Objects:

An object that represents a descriptive aspect of

the domain with no conceptual identity.

These Objects are Immutable and that have no

Uniqueness.
DDD Aggregate

Aggregate:

An aggregate is a collection of Domain Objects /

items that are gathered together to form a total
quantity.

Aggregates have boundary

DDD Aggregate Root
Aggregate Root:

An Aggregate Root is the root Domain Object / item

containing a number of parts that form a whole. In
other words Master Object is called Aggregate
Root.
An AR is more likely to match a Use Case than any
model structure.
An Aggregate root have Global Identity and serves
as a boundary between the objects inside and
those outside
DDD Bounded Contexts

Bounded Contexts:

A division of a larger system that has its own ubiquitous

language and domain model. A division of a larger
system that has its own ubiquitous language and domain
model. A Bounded Context is self contained Mini
Application, Which means as much as possible isolation
is needed from rest of the system.
The communication between bounded contexts might be
using API calls, Events Subscribing from another
bounded contexts. Or one bounded context can be act
like as Client to another bounded context sending
commands and queries.
DDD Context Maps

Context Maps:

Context mapping is a design process where the

contact translations between bounded contexts
are explicitly mapped out. There are several
patterns that can be applied during context
mapping.
1. Shared Kernel
2. Conformist
3. Anti-corruption Layer
DDD Anti Corruption Layer

Anti Corruption Layer:

An Anti-Corruption Layer is a method to isolate

two systems (Bounded Contexts), allowing
systems to be integrated without knowledge of
each other.
Anti Corruption Layer maintain the Integrity of the
System.
DDD Domain Services

Domain Services :

Domain Service is an operation related to

Domain. Ex: Calculation service, Trip Service,
Transfer Service etc.,
These are Stateless Domain Level Services,
which are not logical part of any Entity or Value
Object.
DDD Repositories

Repositories :

Repository Mediates between the domain and

data mapping using a collection-like interface for
accessing domain objects. It is more like a
facade to your data store that pretend like a
collection of your domain
Repository Is Not A Data Access Layer.
Summary

Application code should be a reflection of the

business domain

DDD Reduces the complexity and Increases the

Maintainability.

DDD most suitable to use cases when there is

significant complexity and significant focus on
well defined Business Model.

DDD Increase the testability

It is not the strongest of the
species that survives, nor the
most intelligent that survives.
It is the one that is the most
adaptable to change.
- Charles Darwin