2. 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
4. 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
5. ◦ Meet the business Needs
◦ Helps to Identify the core business
◦ Guide to Create a Correct Software Model
Good &
Effective
Design
5
6. Effective
Design
in DDD
Domain Driven Design offers two types of design tools
for design and develop effective software-
Strategic Design
Tactical Design
6
7.
8. 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
10. Context
◦ Circumstances of an event or
idea or statement
◦ Same thing can behave or act
differently in different context
◦ Context is so important
.
10
14. 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
15. 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
16. 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.
18. 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
22. An Object
Doesn’t have any Identity
Uses as the value of a particular entity
Immutable
Reduces complexity & forces Ubiquitous
Language
Value Object
22
23. 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
24. 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
26. 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
28. Aggregate
28
Collection of Entities and Value Objects which has a
single transactionalboundary
Ensure the transactional consistency of our domain
entities
29. 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
30. 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.
31. 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.
32. Service
There are three types of services
in Domain Driven Design whose
are-
Domain Services
Application Services
Infrastructure Services
32
33. 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
34. 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
36. Store Aggregates into in-memory collection.
We can also get extracted whenever we are
needed.
Example: DbSet of Code First Entity Framework
Repository
36
37. Martin Fowler defined a Pattern for handling
repository in more abstract way
Repository
Pattern
37
Example
41. 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. 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. 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. 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. 45
Aftera while as the requirements are increasing the modelwill become Big Ball of Mud as follows-
46. Big Ball of
Mud
46
A BIG BALL OF MUD is haphazardly structured,
sprawling, sloppy, Spaghetti Code jungle.
49. 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
51. 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.
52. 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
53. 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.
54. 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.
55. 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. 56
Finally our Model is divided into multiple sub domains as
per their responsibilities
58. 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.
59. 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?”
60. 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?”
61. 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?
70. 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