SlideShare a Scribd company logo
Software Architecture Meetup
November 2018
Domain Driven Design (DDD)
Muhammad Ali
Software Architect VentureDive
Conway's law
“Any organization that designs a system (defined more broadly here than just
information systems) will inevitably produce a design whose structure is a copy of the
organization's communication structure.”
What is domain-driven design
● Domain-Driven Design is an approach to the development of complex software in
which we:
○ Focus on core domain
○ Explore models in a creative collaboration of domain practitioners and software practitioners
○ Speak a ubiquitous language with in an explicitly bounded context
Goal
● A domain specific project that needs to leverage multiple realms of expertise
specifically
○ Design and Developer expertise
○ Domain specific expertise
Complication
● Most of the times developers speak in terms of Objects, composition, aggregation,
inheritance, polymorphism, pure functions etc.
● They talk more about technical solution rather than the problem itself.
● At times they don’t understand the underlying complexity and overcommit.
● Domain expert don’t know any of these, he has his own jargons regarding the
domain.
● For example marketing people talking about leads, ads, campaigns, budgeting
units etc.
● Similarly domain expert in airline talking about crew planning, SAFE, roster
planning, FBO, PFA etc.
Solution
● Strengthen the communication process and establish a methodology for making
those communication more robust
● This is primarily accomplished by developing a UBIQUITOUS LANGUAGE and
single model
● Make sure your developers speak this ubiquitous language.
● Persistent use of the UBIQUITOUS LANGUAGE will force the model's
weaknesses into the open
● Building a language like this has a clear outcome:
○ Language and model are strongly interconnected with each other
○ Any changes to the language will be recognized as changes in the domain model
Domain Model
● A system of abstraction that describes selected aspects of a domain and can be
used to solve problems related to that domain.
● A domain model in not a particular(UML) diagram(unlike Model-Driven
Design), it is the idea that diagram is intended to convey.
● Model can be an expression in natural language, code or a diagram.
● Model is not a design artifact
● Model are the backbone of domain-driven design
● The model is distilled knowledge
● It is not just the knowledge in a domain expert's head; it is a rigorously organized
and selective abstraction of that knowledge
Implementation
● Once Domain Model is defined, you can identify different components based on
their properties
● You can divide your solution into different layers(so called layered architecture,
MVP, MVC etc)
● For example following we can break down our solution into following layers
○ Presentation Layer (UI or Rest/SOAP)
○ Application Layer (Define the jobs that software is supposed to do and direct the expressive
domain objects to work out problems.)
○ Domain Layer(Contains Business Logic)
○ Infrastructure Layer(Provides generic technical capabilities, like message sending, persistence etc.)
● There can be multiple layers with different names however Domain-Driven
design only requires domain layer.
Entities
● An object defined primarily by its identity is called an Entity.
● Each entity must have an operational way of establishing its identity with another
object
● An identifying attribute must be guaranteed to be unique within the system
however that system is defined, even if distributed, even when objects are
archived
Value Objects
● An object that represents a descriptive aspect of the domain with no conceptual
identity is called a Value Object.
● The attributes that make up a Value Object should form a conceptual whole
● Immutability should also be considered when designing Value Objects
● As long as a Value Object is immutable, change management is simple
Services
● There are important domain operations that can't find a natural home in an Entity
or Value Object
● A Service is an operation offered as an interface that stands alone in the model,
without encapsulating state, as Entities and Value Objects do.
● Services are a common pattern in technical frameworks, but they can also apply in
the domain layer.
● A good service has following characteristics
○ The interface is defined in terms of other elements of the domain model
○ The operation relates to a domain concept that is not a natural part of an Entity or Value Object.
Aggregates
● An aggregate is a cluster of domain objects that can be treated as a single unit
● Aggregates are the basic element of transfer of data storage - you request to load
or save whole aggregates. Transactions should not cross aggregate boundaries.
● An aggregate will have one of its component objects be the aggregate root.
● Any references from outside the aggregate should only go to the aggregate root.
● The root can thus ensure the integrity of the aggregate as a whole.
● A delete operation must remove everything within the aggregate boundary at
once
● When a change to any object within the aggregate boundary is committed, all
invariants of the whole aggregate must be satisfied. When a change to any object
within the aggregate boundary is committed, all invariants of the whole aggregate
must be satisfied.
Bounded Context
● Bounded Context is a central pattern in Domain-Driven Design
● DDD deals with large models by dividing them into different Bounded Contexts
and being explicit about their interrelationships
● Total unification of the domain model for a large system will not be feasible or
cost-effective
● So instead DDD divides up a large system into Bounded Contexts, each of which
can have a unified model
Context Map
● An individual Bounded Context still does not provide a global view. The context
of other models may still be vague and in flux
● Code reuse between Bounded Context is a hazard to be avoided.
● A Context Map is the overlap between project management and software design.
● A Context Map is a document which outlines the different Bounded Contexts and
the relationships between them.
● The level of detail may vary. What it is important is that everyone working on the
project shares and understands it.
Questions?

More Related Content

PPTX
Practical domain driven design
PDF
DDD Strategic Design - Context Maps - Paulo Clavijo - April 2018
PPTX
Low Level Design
PPTX
Automating Agile Relative Estimation in Arabic Context Using Deep Learning
PPTX
Introduction to UML
PPT
Domain Driven Design (DDD)
PPTX
Domain Driven Design
PDF
Benefits of using software design patterns and when to use design pattern
Practical domain driven design
DDD Strategic Design - Context Maps - Paulo Clavijo - April 2018
Low Level Design
Automating Agile Relative Estimation in Arabic Context Using Deep Learning
Introduction to UML
Domain Driven Design (DDD)
Domain Driven Design
Benefits of using software design patterns and when to use design pattern

Similar to Introduction to Domain driven design (20)

PPTX
Domain Driven Design
PDF
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
PPTX
Unit iv -Documenting and Implementation of Software Architecture
PPTX
DOMAIN DRIVER DESIGN
PPT
Unit IV Software Engineering
PPTX
Domain Driven Design Quickly
PPTX
Domain Driven Design Introduction
PDF
Domain Drive Design: A Very Short Introduction for Business People
PDF
Domain driven design: a gentle introduction
PPTX
Clean architecture
PPTX
DDD eXchange
ODP
Design Patterns Part1
PDF
From class to architecture
PPTX
UNIT_III_Design Engineering, design engineering, architecture, patterns, UML ...
PPTX
Architecture and UML diagrams, types of UML diagrams, types of architecture a...
PDF
Domain Driven Design - Distillation - Chapter 15
PPTX
Domain Driven Design
PPTX
Design Patterns In Scala
PPTX
Intro to Domain Driven Design
PDF
Domain Driven Design
Domain Driven Design
Essential Software Architecture - Chapter 1 Understanding Software Architectu...
Unit iv -Documenting and Implementation of Software Architecture
DOMAIN DRIVER DESIGN
Unit IV Software Engineering
Domain Driven Design Quickly
Domain Driven Design Introduction
Domain Drive Design: A Very Short Introduction for Business People
Domain driven design: a gentle introduction
Clean architecture
DDD eXchange
Design Patterns Part1
From class to architecture
UNIT_III_Design Engineering, design engineering, architecture, patterns, UML ...
Architecture and UML diagrams, types of UML diagrams, types of architecture a...
Domain Driven Design - Distillation - Chapter 15
Domain Driven Design
Design Patterns In Scala
Intro to Domain Driven Design
Domain Driven Design
Ad

More from Muhammad Ali (8)

PPTX
Communication Mechanisms, Past, Present & Future
PPTX
WebRTC Introduction & Basics
PPTX
Introduction to Architectural Katas
PPTX
DBMS Modeling & Optimization
PPTX
Android architectural components
PDF
Architectural katas
PDF
Software Architecture Meetup introduction
PDF
Practicing DDD & CQRS
Communication Mechanisms, Past, Present & Future
WebRTC Introduction & Basics
Introduction to Architectural Katas
DBMS Modeling & Optimization
Android architectural components
Architectural katas
Software Architecture Meetup introduction
Practicing DDD & CQRS
Ad

Recently uploaded (20)

PPTX
Transform Your Business with a Software ERP System
PDF
How Creative Agencies Leverage Project Management Software.pdf
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
PDF
Audit Checklist Design Aligning with ISO, IATF, and Industry Standards — Omne...
PDF
System and Network Administraation Chapter 3
PDF
Design an Analysis of Algorithms I-SECS-1021-03
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
PPTX
ISO 45001 Occupational Health and Safety Management System
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
PPTX
history of c programming in notes for students .pptx
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
PDF
top salesforce developer skills in 2025.pdf
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
PDF
How to Choose the Right IT Partner for Your Business in Malaysia
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
PPTX
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 41
PDF
System and Network Administration Chapter 2
PDF
Adobe Illustrator 28.6 Crack My Vision of Vector Design
PDF
Softaken Excel to vCard Converter Software.pdf
Transform Your Business with a Software ERP System
How Creative Agencies Leverage Project Management Software.pdf
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
Audit Checklist Design Aligning with ISO, IATF, and Industry Standards — Omne...
System and Network Administraation Chapter 3
Design an Analysis of Algorithms I-SECS-1021-03
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
ISO 45001 Occupational Health and Safety Management System
2025 Textile ERP Trends: SAP, Odoo & Oracle
history of c programming in notes for students .pptx
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
top salesforce developer skills in 2025.pdf
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
How to Choose the Right IT Partner for Your Business in Malaysia
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
Internet Downloader Manager (IDM) Crack 6.42 Build 41
System and Network Administration Chapter 2
Adobe Illustrator 28.6 Crack My Vision of Vector Design
Softaken Excel to vCard Converter Software.pdf

Introduction to Domain driven design

  • 2. Domain Driven Design (DDD) Muhammad Ali Software Architect VentureDive
  • 3. Conway's law “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.”
  • 4. What is domain-driven design ● Domain-Driven Design is an approach to the development of complex software in which we: ○ Focus on core domain ○ Explore models in a creative collaboration of domain practitioners and software practitioners ○ Speak a ubiquitous language with in an explicitly bounded context
  • 5. Goal ● A domain specific project that needs to leverage multiple realms of expertise specifically ○ Design and Developer expertise ○ Domain specific expertise
  • 6. Complication ● Most of the times developers speak in terms of Objects, composition, aggregation, inheritance, polymorphism, pure functions etc. ● They talk more about technical solution rather than the problem itself. ● At times they don’t understand the underlying complexity and overcommit. ● Domain expert don’t know any of these, he has his own jargons regarding the domain. ● For example marketing people talking about leads, ads, campaigns, budgeting units etc. ● Similarly domain expert in airline talking about crew planning, SAFE, roster planning, FBO, PFA etc.
  • 7. Solution ● Strengthen the communication process and establish a methodology for making those communication more robust ● This is primarily accomplished by developing a UBIQUITOUS LANGUAGE and single model ● Make sure your developers speak this ubiquitous language. ● Persistent use of the UBIQUITOUS LANGUAGE will force the model's weaknesses into the open ● Building a language like this has a clear outcome: ○ Language and model are strongly interconnected with each other ○ Any changes to the language will be recognized as changes in the domain model
  • 8. Domain Model ● A system of abstraction that describes selected aspects of a domain and can be used to solve problems related to that domain. ● A domain model in not a particular(UML) diagram(unlike Model-Driven Design), it is the idea that diagram is intended to convey. ● Model can be an expression in natural language, code or a diagram. ● Model is not a design artifact ● Model are the backbone of domain-driven design ● The model is distilled knowledge ● It is not just the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of that knowledge
  • 9. Implementation ● Once Domain Model is defined, you can identify different components based on their properties ● You can divide your solution into different layers(so called layered architecture, MVP, MVC etc) ● For example following we can break down our solution into following layers ○ Presentation Layer (UI or Rest/SOAP) ○ Application Layer (Define the jobs that software is supposed to do and direct the expressive domain objects to work out problems.) ○ Domain Layer(Contains Business Logic) ○ Infrastructure Layer(Provides generic technical capabilities, like message sending, persistence etc.) ● There can be multiple layers with different names however Domain-Driven design only requires domain layer.
  • 10. Entities ● An object defined primarily by its identity is called an Entity. ● Each entity must have an operational way of establishing its identity with another object ● An identifying attribute must be guaranteed to be unique within the system however that system is defined, even if distributed, even when objects are archived
  • 11. Value Objects ● An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object. ● The attributes that make up a Value Object should form a conceptual whole ● Immutability should also be considered when designing Value Objects ● As long as a Value Object is immutable, change management is simple
  • 12. Services ● There are important domain operations that can't find a natural home in an Entity or Value Object ● A Service is an operation offered as an interface that stands alone in the model, without encapsulating state, as Entities and Value Objects do. ● Services are a common pattern in technical frameworks, but they can also apply in the domain layer. ● A good service has following characteristics ○ The interface is defined in terms of other elements of the domain model ○ The operation relates to a domain concept that is not a natural part of an Entity or Value Object.
  • 13. Aggregates ● An aggregate is a cluster of domain objects that can be treated as a single unit ● Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. ● An aggregate will have one of its component objects be the aggregate root. ● Any references from outside the aggregate should only go to the aggregate root. ● The root can thus ensure the integrity of the aggregate as a whole. ● A delete operation must remove everything within the aggregate boundary at once ● When a change to any object within the aggregate boundary is committed, all invariants of the whole aggregate must be satisfied. When a change to any object within the aggregate boundary is committed, all invariants of the whole aggregate must be satisfied.
  • 14. Bounded Context ● Bounded Context is a central pattern in Domain-Driven Design ● DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships ● Total unification of the domain model for a large system will not be feasible or cost-effective ● So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model
  • 15. Context Map ● An individual Bounded Context still does not provide a global view. The context of other models may still be vague and in flux ● Code reuse between Bounded Context is a hazard to be avoided. ● A Context Map is the overlap between project management and software design. ● A Context Map is a document which outlines the different Bounded Contexts and the relationships between them. ● The level of detail may vary. What it is important is that everyone working on the project shares and understands it.