Domain Driven Design

What is
Domain Driven
Design
Domain Driven Design is an idea,
first coined by Eric Evans in his
book “Domain Driven Design-
Tackling Complexity in the
Heart of Software” at 2004.
DDD suggests a set of tools and
best practices for developing
software that deliver highest
value.
2

Design
Good or Bad or Effective Design
3

Bad Design
Situations when we use Bad design
◦ Pressure on Delivering the Software
◦ Trying to Save Economywith No Design
Results of Bad Design-
◦ Priorityon Database Design over Business Process and
operations
◦ Trying to Solve Business Problemsusing Shiny
Technologies
◦ Meaningless naming of Objects and Operations
◦ Appoint the Business logics in UI or in Database
4

◦ Meet the business Needs
◦ Helps to Identify the core business
◦ Guide to Create a Correct Software Model
Good &
Effective
Design
5

Effective
Design
in DDD
Domain Driven Design offers two types of design tools
for design and develop effective software-
 Strategic Design
 Tactical Design
6

Strategic
Design
8
Set of Principles thatallows us to
 Segregate domainmodel using Bounded Context
 Develop the Language for Domain Model within the
Bounded Context
 Segregate the Domain into different sub domains
 Mapping between different Bounded Contexts

Context
◦ Circumstances of an event or
idea or statement
◦ Same thing can behave or act
differently in different context
◦ Context is so important
.
10

◦ Any Context that has a defined Boundary
◦ All component of a context
◦ Has specific meaning
◦ Do specific thing
Bounded
Context
12

Ubiquitous
Language
Agile Manifesto says-
Customer collaboration over Contract Negotiation
Collaboration with Customer (Doman Experts)is given the
highest priorityin Domain Driven Design. During
Collaboration team builds a Language which is known as
UbiquitousLanguage.
This language is all about business domain and business
terminology. No technical termswill be uses here.
The UbiquitousLanguagewill reflect the core business
domain and our domain model will be the
implementation of this Language.
EntireTeam will communicateeach other by using this
languageso that everyone properlyunderstand what is
being happening.
14

Sub
Domain
15
A Sub Domain is the part of the overall business domain.
Most business domains are usually too large and complex.
So we logically break down it and divided into different
sub domains based on their responsibilities.
By using Sub Domain we can easily understand our
problem space on a large, complex project.
There are three types of Subdomain-
Core Domain, Generic Subdomain, Supporting Subdomain

Context
Mapping
16
During designing and developing softwareusing Domain
Driven Design we often need to use multiplebounded
context. These contextsalso need to communicatewith
each other. So Context mapping came to the picture.
By using context mapping we relate one bounded context
with another. Or we can also thinklike by using context
mapping our different sub domains are relate with our
core domain.

Types of
Mapping
17
Based on communicationnature there are differenttypes of
mappingare suggests by DDD.

Continuous
Integration
Problem of working multiple members
◦ Breaking down the system into ever-smaller contexts so loses a
valuable level of integration and coherency
Solution
◦ Merging all code and other implementation artifacts frequently
◦ Run Integration Tests to ensure Merging Succeeded.
Continuous Integration Tools
◦ Team City
◦ Jenkins
18

Model
Driven
Design
Design of the software that will
implemented by using the
domain model is called the Model
Driven Design.
21

 An Object
 Doesn’t have any Identity
 Uses as the value of a particular entity
 Immutable
 Reduces complexity & forces Ubiquitous
Language
Value Object
22

Commonly used Value object in C#/Java
String is a value object. It is actually a char
Array. String wraps the char array and gives us
so much business functionalities like
Substring(), Replace(), Trim() etc. If we use char
array for handling all those functionalities then
it would be nightmare for us.
Value Object
23

Example of Value Object:
We can use Money of type float in our entity.
But instead if we create a value object called
Money and handle all validation and domain
logic inside the value object.
Finally call the Money inside entity for defining
the Money property it will make our entity
more ubiquitous as money is of type Money
and make our code more cleaner.
Value Object
24

 An object
 Can uniquely identified by using Id
 Can Consists Value Object
 Mutable
 Can contain validations and domain logics
 Persisted as a row in Database
Entity
26

Aggregate
28
 Collection of Entities and Value Objects which has a
single transactionalboundary
 Ensure the transactional consistency of our domain
entities

Aggregate
29
Example
 We have an Aggregate with three entities Order, Order Info
and Order Items something like follows-
 An Order can have one or more Order Items.
 If any of the Order Items changes then we might need to
change the status of the Order.
 So all of them have strict transaction boundary and they
are consistent all the time

Aggregate
Root
30
All entities and value objects of an Aggregate has a root entity
called the Aggregate Root.
Example:
In Order Aggregate Order is the Root Entity i.e. Aggregate
Root.
Root entity governs the lifetime of all other entities of an
Aggregate
Example:
If we delete the order then relevant Order Items and Order Info
will also remove at the same time.

Domain
Event
31
DomainEventis an eventthatdefined insidethe modelof a
boundedContext.
Sometimeswhen any transactionoccursthen somechanges also
happeninto anotherpart of the domain.In that case we will use
the domainevent.
As soon as somethinghappeninsidethe domainmodelof a
boundedcontextat the same timesomethingalso will happen
inside the domain model ofanotherboundedcontextwhichis
needed.

Service
There are three types of services
in Domain Driven Design whose
are-
 Domain Services
 Application Services
 Infrastructure Services
32

Domain
Services
Act as Façade. Coordinator for
Caching and Transactions.
Example:
Catalog service for ecommerce
domain which deals with all the
catalog related transactions.
33

Application
Services
Application Services are the
services that used in application
level or by the outside world.
Example:
API or Controller are considered as
the Application Service
34

Infrastructure
Services
Communicates directly with
external resources
Example: SMTP
35

Store Aggregates into in-memory collection.
We can also get extracted whenever we are
needed.
Example: DbSet of Code First Entity Framework
Repository
36

Martin Fowler defined a Pattern for handling
repository in more abstract way
Repository
Pattern
37
Example

Factory
38
A Method for creating the instance of
Domain Model whenever needed.

Layred
Architecture
39
Onion Architecture

40
Case Study
Agile Product Management Tool for Scrum

41
 Core Conceptis a Product will develop
 Product has BacklogItems,Releases & Sprints
 Each BacklogItem has a number of Tasks
 Each Taskcan have collectionof Estimation Log Entries
 Release have ScheduledBacklog Items
 Sprints have Committed Backlog Item

42
Then the client increased their requirements.They also need-
 Subscribing optionforall subscriberOrganization
 User optionfor each subscriber
 Levelof Permissionsforeach user
 A Discussion panel as Collaboration tool
So our modelsize increased

43
Again client increased their requirements.Now they need-
 A Forum forCategorywise discussionlike ProductDiscussion,Release Discussion,Sprint
BacklogDiscussion etc.
 Calendar entry system for set the milestones
So again our modelsize increased-

44
Then they added more requirementfor
 Will have a option for make a Team
 Track the Time Consuming Resources ina Sprint
 Resource Manager for setting up Time and Availability of Team Members and ProductOwner

45
Aftera while as the requirements are increasing the modelwill become Big Ball of Mud as follows-

Big Ball of
Mud
46
A BIG BALL OF MUD is haphazardly structured,
sprawling, sloppy, Spaghetti Code jungle.

48
Collaborate Domain Expert and Team to Identifywhat is Core and build the Ubiquitous Language

49
Why Collaborationis so Important?
 Domain expert has the every business knowledge and it’s processes
 Developersonly know how to code,uses best frameworks,Database Tools etc.
So it order to gather business knowledge,Identify the core and build Ubiquitous language Collaboration
is so important

Identify the Core
Challenge & Unify

Challenge-01
Shall we add all concepts of large model to
Ubiquitous Language of Scrum?
51
Answer is No because-
Tenant, User and Permission has nothing to
do with Scrum. So they should be out of our
Scrum software model.

Challenge-02
52
Is there anything missing in Scrum model?
Three core concepts of Scrum i.e. Product
Owner, Team and Team Members are
missing here. So need to add with Scrum
model

Challenge-03
53
Are Support Plans and Payments really
goes with Scrum Project Management?
No. Both Support-Plans and Payments will
be managed under a Tenant’s Account, but
these are not part of our core Scrum
language.

Challenge-04
54
What about Human Resource concerns?
They will not directly used by Product owner
or Team Members. So they will be out of
Scrum Context.

Challenge-5
55
Would Milestones, Retrospectives, Reminders,
Plans etc. be in the core model of Scrum?
Calendar-based Milestones, Retrospectives, Reminders,
Plans etc. are in context. But the team would prefer to
save those modeling efforts for a later sprint. They are in
context, but for now they are out of scope.

56
Finally our Model is divided into multiple sub domains as
per their responsibilities

Developing
Ubiquitous Language

Tool for
Developing UL
58
During collaboration with Domain Expert-
 What are the Domain Model is supposed to do
 How the Domain Model Should Work
 What are the various components of the model
 What those components are do and how
How to build such Scenario?
Develop Concrete Scenarios that are specifically
focus around a domain model.

Tool for
Developing UL
59
The Answer will be “The Product Owner”. So
the Scenario will be refine as follows-
Now we have our Scenario.
Carefully brainstorm and refine the Scenario-
Ask Domain Expert-
“Who commit the backlog item to a sprint?”

Tool for
Developing UL
60
The Answer will be “No”.
It depends on the Teams agreement about
how much they will be able to complete
within a sprint duration.
Ask Domain Expert-
“Would the Product Owner be able to
Commit backlog item as much as want?”

Tool for
Developing UL
61
The Answer will be “Sprint”
So change and refine our UL again-
Ask Domain Expert-
Who are the interested parties?

Identify
Subdomains
63
Identify the sub Domains as per the
responsibilities of our Bounded Contexts

Aggregate
Rules of
Thumb
65
Protect Business Invariants
Each individual Aggregate will have
separate Transactional Boundary. So they
will Committed or Rolled back separately

Aggregate
Rules of
Thumb
66
Design Small Aggregate
Large Aggregate can causes
Transactional Failure.

Aggregate
Rules of
Thumb
67
Design Small Aggregate
Keep Aggregate as small as possible

Aggregate
Rules of
Thumb
68
Reference Other Aggregate by Id
To Save Memory Consumption Refer by Id
instead of entire Aggregate

Aggregate
Rules of
Thumb
69
Update Other Aggregate Eventually
Use Domain Events when needed to
update other Aggregate during updating a
Aggregate

Aggregate
Rules of
Thumb
70
Update Other Aggregate Eventually- Example
After committing the Backlog item to a Sprit
the Committing Sprint need to Notify. So we
will use Domain Event to notify the Sprint

Md. Mojammel Haque
CSM, CSPO, CSD, CSP (Scrum Alliance)
Software Architect, Raven Systems Ltd.
http://www.codermojam.com
codermojam@gmail.com
http://github.com/mojamcpds
https://www.linkedin.com/in/mojamhaque/
Cell- +8801795231350, 01817045882

Domain Driven Design

More Related Content

What's hot (18)

Similar to Domain Driven Design (20)

More from Mojammel Haque (6)

Recently uploaded (20)

Domain Driven Design