An introduction to Domain Driven Design, including definitions of domain experts, ubiquitous language, domains and subdomains, models, bounded contexts and context maps

1. A gentle introduction
to domain-driven
design
Eleonora Ciceri - 12 January 2022
1

2. The rationale: why domain-driven? (1)
Communication issues in projects are often the cause for project failures
These issues can manifest themselves in different ways:
- unclear requirements
- uncertain project goals
- ineffective coordination
- ineffective effort
2

3. The rationale: why domain-driven? (2)
Domain-driven design (in short, DDD) focuses on effective communication:
What do we gain? Guide decisions according to the business strategy
3
DDD strategic tools
Analyze business domain and strategy to foster a
shared understanding of the business between
stakeholders
DDD tactical tools
Write code in a way that reflects the business
domain, addresses its goals and speaks the
language of the business

4. Analyzing a business domain
4

5. What is a business domain?
A business domain defines a company’s main area of activity
5
“sells coffee” “provides
courier delivery”

6. What is a subdomain?
A subdomain is a fine-grained area of business activity
The subdomain have to interact with each other to achieve the company’s
goal in its business domain
6
business domain
(some) subdomains
buy real
estate
hire
personnel
manage
finances
sell coffee
divides into

7. Core subdomain
A core subdomain is what a company does differently from its competitors
- inventing new products or services
- reducing costs by optimizing existing processes
7
Uber
Ridesharing
Jewelry maker
Jewelry design
Google
Ranking algorithm

8. Generic subdomain
A generic subdomain is a business activity that all companies perform in the
same way
- do not provide competitive advantage
- no need for innovation or optimization (use what is available!)
8
Jewelry maker
Online shop
Uber
Authc/z

9. Supporting domain
A supporting domain supports the company’s business without providing
competitive advantage
9
Online advertising company
Storing and indexing creative
materials (banners, landing
pages…)

10. Comparing subdomains
10

11. Solution strategy
All subdomains are required for the business domain to work!
11
Core subdomain Generic subdomain
Supporting
subdomain
has to be implemented in-house
(if adopted from someone else, it would undermine
the notion of competitive advantage, as the
company’s competitors would be able to do the same
thing we do)
cost-effective to buy as off-the-shelf
product or adopt an open-source
solution
(hard but already solved problems)
a rapid application development
framework will suffice to implement the
business logic without introducing
complexity
(do not require elaborate design patterns)

12. How do we identify subdomains?
Start from the company’s departments and other organizational units. Then,
investigate inner workings and see if a department is composed of
finer-grained components
12

13. Identifying the domain experts
13

14. Who are the domain experts?
Domain experts are subject matter experts who know the business that we
are going to model and implement in code
The software is supposed to solve their problems
14
What they are
- knowledge authorities in the business
domain
- people coming up with requirements
- end users
What they are NOT
- analysts gathering requirements
- engineers designing the system

15. Discovering domain knowledge:
Ubiquitous language
15

16. Business problems
The software systems we build are solutions to business problems, both at
business domain and subdomain
16
business domain/subdomains
courier delivery
knowledge management
clearing subdomain
accounting subdomain
business problems
ship packages in limited time frame
optimize information storage/retrieval
optimize the execution of financial transactions
optimize the shipping process

17. Traditional SW development lifecycle: flaws
17
interviews conducted by analysts, without
engineers, sometimes without domain experts
written documents that
become outdated
wrong or distorted
understanding of problem and
requirements
wrong solution, or right solution
to the wrong problem
A chain of translations
distills the wrong
domain knowledge and
leads to the wrong
software

18. Knowledge discovery
To design a software solution, we have to grasp and distill the basic
knowledge of the business domain
18
the knowledge belongs to
domain experts
it is their job to understand the intricacies
of the business domain
we are not domain experts
it is NOT our job to understand the
intricacies of the business domain
The software has to mimic the
domain experts’ way of thinking
about the problem
Without an understanding of the
business problem and the reasoning
behind the requirements, our
solution may fail to describe a
business concept

19. Knowledge discovery needs the proper language
To grasp and distill the basic knowledge of the business domain, the parties
involved need to speak the same language
- we do not have to make up the language
- we need to use the actual, existing language of the domain
19

20. Ubiquitous language
Using a ubiquitous language is the cornerstone practice of domain-driven
design
Idea: if parties need to communicate efficiently, instead of relying on
translations, they have to speak the same language
20
software
engineer
product
owner
domain
expert
UI/UX
designer
All should use the
ubiquitous language
when describing the
business domain

21. No technical jargon!
21
“the order can be published only if it has at
least one associated record in the customer
table”
“the advertisement iframe displays an HTML
file”
“we acquire real-time data using a sensor”

22. Formulate statements in the language of business
22
“an advertising campaign can display different
creative materials”
“an order can be placed only if at least one of
the contained items is available”
“sales commissions are accounted for after
transactions are approved”

23. Language consistency: ambiguous terms
Ambiguity hinders communication, so each term of the ubiquitous language
should have one and only one meaning
If a term is ambiguous, replace it with something that is not
23
policy
regulatory rule
insurance contract

24. Language consistency: synonymous terms
Two terms cannot be used interchangeably in a ubiquitous language, e.g.,
user, visitor, administrator, account…
Often these synonyms denotes different concepts, e.g.,
- “visitor” may be used only for analysis purposes in a website, as he is not
registered
- “account” actually uses the system and its functionality
24

25. Discovering domain knowledge:
Model of the business domain
25

26. What is a model?
“A model is a simplified representation of thing or phenomenon that intentionally
emphasizes certain aspects while ignoring others”
– Rebecca Wirfs-Brock
A model is NOT a copy of the real world; it is a human construct that helps us
make sense of real-world systems
26
Canonical example: a map is a model
that does not represent all the details of
our planet, but contains enough data to
support its particular purpose, i.e., the
problem it is supposed to solve

27. Effective modeling
All models have a purpose, and an effective model contains only the details
needed to fulfill its purpose
Just omit unnecessary details and leave only what is needed for solving the
problem at hand
27
there are no subway stops
on world maps
you cannot use a subway
may to estimate distances

28. Modeling the business domain
The business domain model is supposed to:
- capture the domain experts’ mental models (i.e., their thought
processes about how the business works to implement its function)
- include just enough aspects of the business domain to make it possible
to implement the required system
28
When solving the arrhythmia detection
problem we shall model ECG signals…
… not the heart vessels!

29. Modeling is a continuous effort
The ubiquitous language should be continuously reinforced throughout the
project. All the following should use this language:
- requirements
- tests
- documentation
- source code
Cultivation of a ubiquitous language is an ongoing process. Everyday use of
the language will reveal deeper insights into the business domain
29

30. Tools for managing the ubiquitous language
30
glossary
It maintains nouns (names of entities, processes, roles etc.)
It has to be maintained by all team members, not just by
architects and team leaders!
tests
Tests in Gherkin language can capture the ubiquitous
language but also to describe behavior (business logic, its
rules, assumptions, invariants)

31. Managing domain complexity
31

32. Context is what gives words a meaning
Some words have different meanings depending on the context in which they
are used
32

33. Squeezing diversified knowledge into the model
Suppose we have two experts who do not agree on the ubiquitous language:
Seems like we are mixing domain concepts from different contexts. This is
why we have to introduce bounded contexts
33
Expert from marketing department
“a lead is a notification that somebody
is interested in one product”
Expert from sales department
“a lead represents the entire lifecycle of
the sales process”

34. Bounded contexts
The solution in domain-driven design is trivial:
divide the ubiquitous language into multiple (smaller) languages, then assign
each one to the explicit context in which it can be applied
The contexts in which we apply these smaller languages are called bounded
contexts
34
A ubiquitous language in
one bounded context can
be completely irrelevant
to the scope of another
bounded context

35. Bounded contexts vs Subdomains
35
Subdomain
A subdomain resembles a set of interrelated use cases
Use cases are defined by:
- business domain
- system requirements
We do NOT define the requirements, that is the
responsibility of business
Bounded context
A bounded context is designed (and choosing its
boundaries is a strategic design decision)
We decide here how to divide the business domain into
smaller, manageable problem domains
Relationship between subdomain and bounded context:
- Having a one-to-one relationship between bounded contexts and subdomains can be
reasonable in some scenarios
- In other scenarios, different decomposition strategies can be more suitable: it could be
beneficial to use multiple models of the same concept to solve different problems

36. A practical example: model for a refrigerator (1)
This is a model of a refrigerator:
No, it’s not a refrigerator, but it models the refrigerator without copying the
real-world entity. It has a purpose – a problem it is supposed to solve
36

37. A practical example: model for a refrigerator (2)
The problem it solves is checking whether the refrigerator can fit through the
kitchen door
The cardboard does not look like the fridge, but building a 3D model would
not solve the problem more efficiently than the cardboard. Thus, building a 3D
would be called overengineering
37

38. A practical example: model for a refrigerator (3)
The cardboard model, though, cannot check if the height of the refrigerator is
adequate.
We need a second model for the same fridge:
Each model has its bounded context (the cardboard verifying that the base
makes through the entry, the tape measure verifying that it is not too tall)
38

39. Integrating bounded contexts
39

40. Contracts between bounded contexts
Bounded contexts themselves are not independent
- a system may be built of components
- components have to interact with one another to achieve the system’s
overarching goal
There are touchpoints between bounded contexts, called contracts or
integration patterns
40

41. Integration patterns: Cooperation
Cooperation patterns relate to bounded contexts implemented by teams with
well-established communication or by a single team
Partnership. Each team develops its own
bounded context, integration is done
collaboratively
Shared kernel. The same (sub-)model is
implemented in multiple bounded contexts. It
introduces dependencies between contexts: it has
to be applied only when the cost of duplicating code
is higher than the cost of coordination
41

42. Integration patterns: Customer-Supplier (1)
Customer-supplier patterns have a service provider (upstream) and a
consumer (downstream) that interact
Here teams are independent, and in most cases we have an imbalance of
power: either the upstream or the downstream team dictate the integration
contract
42

43. Integration patterns: Customer-Supplier (2)
Conformist. If the upstream does not have
motivation to support the downstream needs, it
defines the integration contract, defined according
to its own model. If the downstream accepts the
contract, it is called conformist.
Anti-corruption layer. The upstream service has still
the power of the relationship. However, the
downstream is not willing to conform. Thus, it will
translate the upstream bounded model into a model
tailored to its own needs. The anti-corruption layer
performs the translation, so that the downstream is
isolated from foreign concepts
43

44. Integration patterns: Customer-Supplier (3)
Open-Host Service. Here the upstream wants to
provide the consumer the best service possible. The
upstream decouples the implementation model from
the public interface: it implements its model, but offers
a public protocol that is convenient for the consumer
(also called the published language)
It is also possible to create multiple versions of the published
language, to serve different downstream applications or to
allow the downstream to migrate to new versions gradually
44

45. Integration patterns: Separate ways
The last collaboration option is not collaborate at all, e.g., there are teams
unwilling to collaborate:
- Communication issues: when teams have a hard time collaborating, it is
more cost-effective to go separate ways and duplicate functionalities in
multiple bounded contexts
- Generic subdomains: if the subdomain is generic it is more cost-effective
to integrate it locally in each bounded context (e.g., logging: one of the
contexts expose it as a service and the other use it)
45

46. Context maps
46

47. Context map
A context map is a visual representation of the system’s bounded contexts
and the integrations between them
47

48. Why using context maps?
For many purposes:
- High-level design: a context map provides an overview of the system’s
components and its models
- Communication patterns: a context map depicts the communication
patterns among teams, e.g., which teams are collaborating and which
prefer less intimate integration patterns
- Organizational issues: a context map can give insight into organizational
issues. E.g., what does it mean if the consumers for a certain upstream
team all resort to implementing an ACL?
- Documentation: sharing the effort of updating the context map over
different teams helps in building a shared documentation
48

49. References
49

50. References
[1] Vlad Khononov, Learning Domain-Driven Design - Aligning Software
Architecture and Business Strategy, O’Reilly, 2022
50