This document provides an overview of Domain-Driven Design (DDD) concepts including: - The common language shared between domain experts and software developers. - Using models to capture the semantics of the domain language. - Identifying multiple domain models with clear boundaries and mappings between them. - Nesting boundaries at different levels of granularity such as sub-domains, bounded contexts, and aggregates. - Key DDD patterns like entities, values, events, commands, and aggregates.

1. Domain-Driven Design
A Gentle Introduction into Challenging Topic
Asher Sterkin
asher.sterkin@gmail.com
Clean Code Meetup
January 2, AppsFlyer

2. About DDD IL
Asher SterkinVladik Khononov Erik Ashepa
● White belt circle: spread the word about DDD
● Black belt circle: apply DDD to real problems
Feel free to reach out if you want to join any of them

3. About Myself
● Software technologist/architect
● Almost 40 years in the field
● Former VP Technology @ NDS and Distinguished Engineer @ Cisco
● Currently CTO @ IRKI
● C-level mentoring on software strategy
● Cross-discipline approach (connecting the dots):
○ (Strategic) Domain-Driven Design
○ Serverless Architecture
○ Cynefin
○ Wardley Maps
○ Lean Startup
○ Promise Theory
○ ...

4. ● Just an overview of the main DDD concepts
● All examples are purely illustrative
● No architectural or technological recommendations
● All wording is mine, as well as mistakes
Disclaimer

5. Domain-Driven Design is More Relevant than Ever
● Software infrastructure is rapidly commoditized
● Focus on delivering business value “yesterday”
● AI, AR, VR, 3DP, IoT, Blockchain spiral complexity up
● Need a practical method to keep complexity under control
● So far DDD has an unsurpassed record in this area

6. Domain-Driven Design Acronym
L
M
B
N
Pronounced LA-M-BA-N (invention is mine)

7. Domain-Driven Design at a Glance
Language
Model
Boundaries
Nesting

8. Language
● Common (ubiquitous) language for domain
and software experts
● Vocabulary reflected directly in software
● Normally a subset of domain-specific jargon
DDD is essentially a linguistic process

9. Model
• Language elements have meaning (semantics)
• Semantics is captured in a form of formal model:
– Object-Oriented
– Statecharts
– Functional
– Relational
– Graph
– Mathematical
– Neural Networks
– …
DDD is also a modeling process

10. Boundaries
● “One size fits all” models are impractical
● G-d like models result in Big Ball of Mud
● DDD insists on identifying multiple models:
○ Coherent within their own boundaries
○ Mapped onto others where
appropriate
DDD is about maintaining boundaries for- and mappings between- models

11. Example
SW? SW?
?

12. Example
SWHR SWFN
Employee, Salary, Bonus, ...

13. Nesting
● Boundaries exist at different levels of granularity
● Within DDD approach the following levels of granularity are considered:
○ Conceptual boundaries (sub-domains)
○ Application and Domain Services
○ Bounded Context
○ Stateless vs Stateful Elements
○ Aggregate
○ Entity
○ Value
● It’s possible to stop at any level and still have some value
● Not all parts of the system will be designed equally well!

14. Sub-domains
Generic Services
Supporting Services
Core
?
?
?

15. Sub-domains (popular version)
Generic Services
Supporting Services
Core
Needs to be done, but no advantage
Makes you money
3rd party products/services, no advantage

16. Example (my approach)
Generic Services
Supporting Services
Core
...
...
Green Invoice
push down
pull up
Generic for any domain
Common for group of domains
Essense of my business
Strategic Impact: build, buy, contribute

17. CDN
Application vs Domain Services (oversimplified)
users
things
robots
UI devices
Application Services Domain ServicesDDD is primarily focused on thisSome practitioners believe that
applying DDD here would be an
overkill, some others do not
IoT Device
Gateway
API Gateway
IoT Protocol
Gateway
API Gateway App Service
Domain Service
Domain Service
App Cache
App Service
App Service
Event Stream

18. Example
Clients App Services Domain Services
? ? ?

19. Textbook Example: Netflix API
App API App Services Domain API Domain API

20. Bounded Context
Bounded Context
Domain Model
Ubiquitous Language Nouns, Adjectives, Imperative Verbs, Interrogative Verbs, Perfect Tense
Verbs, Syntax, Grammar
Entities, Values, Commands, Queries, Events, Aggregates, Repository,
Computational Services, Factories, Anti-Corruption Layer, Saga
Bounded Context
Domain Model
Ubiquitous Language
context map
● Linguistic boundaries
● Reflect commitment to maintain strong cohesion inside and loose coupling outside
● Inside Bounded Context the model could evolve independently
● Defines a Minimal Meaningful scope with Maximum Acceptable Risk of not having semantic
consistency across different parts of the system (not too much, not too little)

21. Example
Bounded Context
?
Bounded Context
?
?

22. Example (my system at the moment)
Bounded Context
Front
Office
Bounded Context
Back Office
Bounded Context
Product
Design
Green Invoice

23. Stateless vs Stateful
Saga
Stateless
Computation
Stateful Object
Implements a multi-step
workflow. Needs state to
keep track of progress
and run compensating
transactions in the case of
failure
Stateful Objects introduced
when managing State is a part
of the Domain Service contract
Performs computation which does not
naturally fit into any stateful object. In
particular could be a Factory for some
Stateful Object with complex creation process

24. Example
Workflow
?
Stateless
Computation
?
Stateful Object
?

25. Example (mine)
Workflow
Product Item
Registration
Stateless
Computation
Resize
Picture
Product Catalog
Pictures
Product Types
Colors

26. Strong Transaction
Consistency + Invariant
DDD Aggregate and Repository
<<Aggregate Root>>
Entity
Entity Value
Value
Eventual
Transaction
Consistency
aggregate storage
store/retrieve requests -->
command/query requests -->
update/query method call -->
● Data integrity boundaries
● Reflects commitment to maintain strong transactional consistency
inside and eventual consistency outside
● Inner parts are accessible only via Aggregate Root
● Inside Aggregate some form of invariant is maintained
● Aggregates of the same type are stored within Repository
● Defines a Minimal Meaningful transactional scope with Maximum
Acceptable Risk level of not having immediate data consistency
across different parts of the system (not too much, not too little)
Command/query
Request Processor
Aggregate
Repository
Aggregate

27. DDD Entity, Value, Event, and Command
<<Aggregate Root>>
Entity
Entity Value
Value
Puts boundaries
around some identity,
which has state and
history
<<Aggregate Root>>
Entity
Ref
Value
Many Aggregates are
flat, but some have
nested Entities
Does not have identity or history. Encapsulates raw data types
(e.g. Integer, String) to supply meaningful names from
Ubiquitous Language (e.g. Street) including external references
to other Aggregates
Event
Something interesting
happened
Command
Way to send
an update
request to
Aggregate

28. Example
Event
?
<<Aggregate Root>>
?
Value
?
Command
?

29. Example (mine)
Tariff
Changed
<<Aggregate Root>>
ProductType
Tariff
Necklace
Bracelet
Earrings
...
Operation Beadwork
Clasp
...
Currency NIS
Change
Tariff

30. Advanced Topics not Covered Here
● Strategic DDD Patterns
● Context Mapping
● Command-Query Request Segregation (CQRS)
● Event Sourcing (ES)
● Dealing with Legacy Systems
● Event Storming
● DDD and Microservices (Erik’s talk)
● Cloud-native and Serverless DDD (area of my research)
● DDD and Machine/Deep Learning
● DDD and IoT
● DDD and VR/AR
● ...

31. DDD Bookshelf

32. DDD Video Library
● Eric Evans: Tackling Complexity in the Heart of Software
● Eric Evans: Good Design is Imperfect Design
● Eric Evans: DDD & Microservices: At Last, Some Boundaries!
● Eric Evans: Acknowledging CAP at the Root -- in the Domain Model
● Many, many more on YouTube and Vimeo
●

33. DDD Online
● Eric Evans’ site: https://domainlanguage.com/
● Domain-Driven Design on InfoQ: https://www.infoq.com/domain-driven-design
● Long curated list at https://github.com/heynickc/awesome-ddd
● Vladik’s Blog at http://vladikk.com/
●

34. A Shameless Promotion