Pragmatic DDD Guide

DOMAIN-DRIVEN
DESIGN
A pragmatic approach
EBOOK
by Eduard Ghergu
INTRODUCTION ........................................................... 04
01
WHY DOMAIN-DRIVEN DESIGN? ..................................................... 05
02
WHAT IS DOMAIN-DRIVEN DESIGN? ............................................... 08
WHY DO WE NEED DOMAIN-DRIVEN DESIGN? ................................
03 12
DOMAIN-DRIVEN DESIGN BUILDING BLOCKS ................................
04
Ubiquitous Language ....................................................................................................
Bounded Context / Context Maps ................................................................................
Domain [8] ....................................................................................................................

17
19
20
22
Model [8] ....................................................................................................................... 23
DOMAIN-DRIVEN DESIGN PATTERNS .............................................
05 24
THE E-COMMERCE DOMAIN-DRIVEN DESIGNED SAMPLE ............... 27
06
Introduction .................................................................................................................
Requirements and Modelling [12] ...............................................................................
The Software Architecture ..........................................................................................

28
30
33
07
CONCLUSIONS ................................................................................ 38
08
REFERENCES ................................................................................... 40
FIGURES
FIGURE 1 UBIQUITOUS LANGUAGE [5] ............................................ 10
FIGURE 2 CONTEXT MAPS [5] .......................................................... 11
FIGURE 3 DOMAIN-DRIVEN DESIGN LANDSCAPE [9] ...................... 13
FIGURE 4 HIGH LEVEL E-COMMERCE SAMPLE DOMAIN [11] ........... 14
FIGURE 5 HIGH LEVEL E-COMMERCE SAMPLE DOMAIN, DDD [11] .. 14
FIGURE 6 THE OBJECT INTERACTION DIAGRAM ............................. 15
FIGURE 7 THE OBJECT RESPONSIBILITIES DIAGRAM .................... 16
FIGURE 8 CLASS DIAGRAM ............................................................. 17
FIGURE 9 ORIGINAL VIEW .............................................................. 18
FIGURE 10 AN ALTERNATIVE VIEW ................................................. 19
FIGURE 11 CLEAN ARCHITECTURE DOWN TO EARTH VIEW ............ 20

As an approach to software architecture, Domain-Driven Design (DDD) has
become more and more popular lately because of the increased use of
microservices. The main reason for this, from the architect’s point of view,
is that structuring software around bounded contexts and aggregates is
perfect for microservice specialization. Simultaneously, stakeholders and
users benefit from a consistent orientation to the domain’s expertise as
well as a ubiquitous language that helps project the company’s business
intricacies into the source code.
This book does not introduce any new concepts; it attempts to concisely
summarize the essence of DDD, giving you a crash course on the
fundamentals.
Domain-Driven Design 04
Why Domain-Driven
. Design?
Because we need a way to eliminate
the following:
Almost all of us have experienced, or still

are experiencing, late delivery because
1 of unclear requirements, a last-minute
Late customer change of mind, or other reasons
Delivery
that are not necessarily linked to the
development team.
In some cases. Of course, we are going to

focus on what is really needed and maybe 2
let some requirements or functionalities out Stripped-down
because of time or price constraints. functionality
3 Sometimes there are misunderstandings

and the final product is not actually what
Not aligning with
customer needs was expected from us.
Changes are sometimes difficult due to the 4

Complicated
structure that has been already created.
changes
As long the application logic is implemented
in more than one functional component
(a violation of the Single Responsibility
Principle - SRP [1]), any change to the
functionality is risky without a clear
5 understanding of the business requirement.
Hard-to-fix, time- Also, if the model that is going to be changed
consuming bugs is used by many different modules (for
example the same Customer is used in
Orders, Payments, Shipping, etc.), any new
requested functionality for a module will
have a direct impact on the others sharing
the same model or functionality.
Usually, there is a tight coupling between

different layers of an application; different
“entities”, if any were defined, are just
anemic models [2] with a state (members,
properties) but without business logic that 6
Functionality
is “outsourced” to external components scattered over
like services, managers, even ORM related many places
classes, etc. In the end, the logic for a
specific functionality can be found in
controllers, managers, services, etc.
7 Related to violations of software design

Many other principles and practices.
issues
What is
Domain-Driven
. Design?
It is a design methodology defined by Eric Evans in his seminal book,
Domain-Driven Design: Tackling Complexity in the Heart of Software
(Addison-Wesley Professional, 2003). This approach to software
development enables teams to effectively manage software construction
and maintenance for complex problem domains. It also emphasizes the
need to understand and match the business domain for the application
that is going to be implemented.
However, despite its obvious strong advantages, it’s not a silver bullet,
and it cannot be used everywhere or under any condition. It is, mainly,
a set of recommendations, best practices, building blocks, and patterns
that can be used to overcome some of the development problems that
usually arise in application construction.
As software developers, we need to “translate” the real-world business

domain into a form that can be used to create the application’s code—a
domain model. This is an essential part of our software design. It will also
be a communication vehicle between domain experts, and the software
development team.
Domain-Driven Design favors the Separation of Concerns (SoC) design

principle [3]. The different parts of an application get separated, so
we are trying to isolate different parts of the functionality into very
specific modules to avoid cluttering the code and having unnecessary
dependencies that are hard to change and maintain.
Typically, a complex problem may be broken down into smaller problems

that are much easier to solve. Similarly, a complex business domain can
be “split” into sub-domains with de ined roles and goals that are simply
modeled—an application of SoC [3].
Consider an ERP system: how can we model and implement such a
system as best as possible? We may have several components that
collaborate, such as customers, production, warehousing, and a variety
of other concerns that we must deal with in some way. As a result, the
goal is to break things down into smaller “pieces” and treat them as
independently as possible. However, not all sub-domains are equally
important; for the important ones (the core), it is necessary to invest
more time and effort to understand them correctly. The others are just
details, and they will not necessarily be implemented by us. In this case,
it will be sufficient for a sample to acquire a solution that already exists
on the market that can solve a smaller problem or a problem that is not
very important for the core of the business or for the core of the system
we are dealing with. The core, which is the main area of the business, is
what differentiates the company from the competition. Without it, the
company will be pushed out of the market.
If we take a step back and think from the developer perspective, the
team usually includes a business analyst, or, if the project is an agile one,
a product owner who acts as an intermediary between the business and
the development team. In this case, all communication usually passes
through this business analyst or product owner, but it’s not always the
best approach given the gaps between the business world and the
development world. The most important aspect of domain-driven design
is communication, and—this is what people should take note of—requires
greater cooperation between domain specialists, those who understand
how the company operates, and the development team. Businesses
will communicate in their own terminology, such as accounts, debiting,
crediting, etc., while developers will understand something different.
Therefore, it’s critical to establish a common understanding and,
ultimately, a common language in which to communicate.
To conclude, DDD’s key objectives are:
• Centering the project’s focus on the business domain and its logic.
• Employing a domain model to facilitate creating complex designs.
• Establishing a collaborative effort between technical and domain

experts to iteratively refine a conceptual model that addresses specific
domain problems.
Why do we need
Domain-Driven
. Design?
The primary advantages:
1
Helps the teams create a common model.
The business and developer teams can then
use this model to communicate the business
Eases
Communication requirements, data entities, and process
models.
This implies that almost everything in the

domain model is based on an object and
therefore will be modular and encapsulated,
enabling the system to be changed and
improved regularly and continuously.
Domain-Driven Design provides flexibility
because it encourages the Separation of
Concerns and the isolation of different parts
2
of the domain that represent knowledge
Provides
from the business side. After a couple of Flexibility
rounds of discussions and idea exchange,
the various teams working to create the
business domain model will eventually
come up with a model that is more suited
for implementation and matches customer
expectations.
Gives software developers the principles
and patterns to solve tough problems in
software and, at times, in business. Here,
it’s also important to understand that an
approach based on Domain-Driven Design
will help the synchronization between
business and development. That means that
the model created by developers will reflect
3
the business domain, but also that this
model may influence the business and its
inner behavior.
Improved
As developers or technical experts, we’ll
Patterns
start by analyzing the business domain and
trying to model it.
Because the business team may not have
a clear picture of all the details up-front,
the feedback that they receive from the
technical team will help them in improving
their understanding of how business works
and, maybe, identifying any gaps or
difficult-to-solve impediments.
Requirements are always explained from

a domain perspective. Conceptualizing
the software system in terms of the
business domain reduces the risk of
misunderstandings between the domain
experts and the development team.
Effective communication and a common
language will, of course, help to reduce
the risk of misunderstandings. Effective
communication between business and
4
development teams will most likely be Reduced Risk of
difficult at first, but by working together Misunderstandings
and developing a common language, the
number of misunderstandings or issues
caused by different points of view will
gradually decrease. As a result, the number
of iterations needed to gather requirements
or understand the details of the problem
we’re trying to solve as technical experts will
decrease over time.
Nothing is 100% suitable for every
single use-case, and, of course,
there are also some disadvantages:
The main disadvantage of introducing

Domain-Driven Design in software
development is the additional effort and
time required to create a substantial model
of the business domain before positive
effects on the development process become
apparent.
Domain-Driven Design is a methodology
that usually fits very well in the case of quite
1 complex systems or solutions. For example,
if we are going to implement a To-Do
Additional
application or a small website for a client,
Effort Required
it makes very little to no sense to invest in
Domain-Driven Design because it will take
a significant amount of time to understand
and model the business. However, even for
simple applications, we can probably use
domain-driven design building blocks and
patterns to benefit from the advantages of
having cleaner code and a clean architecture
in the end.
If not available ‘in-house’, they are often
expensive to hire since they hold valuable
knowledge.
Domain experts are required for a complex
business, so we will need a team of them
who can contribute to knowledge sharing
and explain concepts to the technical team
that will use the gathered knowledge to 2
create good business models. This is an
issue, though, because domain experts Requires
are usually busy people who aren’t always Domain Experts
available, and getting everyone in the same
room is difficult. So, keep this in mind when
estimating the time required to gather
knowledge from various domain experts
if you’re working on creating or upgrading
an existing system with complex business
needs.
The purpose of Domain-Driven Design is to

3 simplify complexity. It is a great approach to
software development if there is a need to
Suitable simplify, but for simple applications, using
for Complex
Domain-Driven Design is not worth the
Applications
effort.
A high level of isolation and encapsulation

in a domain model may present a challenge
4
for business domain experts; that’s why it’s High
important to avoid the technical details in Encapsulation
the design phase. can be an issue
Domain-Driven
Design Building
. Blocks
The main Domain-Driven Design
concepts (or building blocks) are [4]:
The language that the technical team will

develop in collaboration with domain experts Ubiquitous
to share a common understanding of the Language
problem that has to be solved.
Bounded
This concept was introduced to
Context / isolate specific areas of the business
Context from each other.
Maps
A sphere of knowledge (ontology), influence,

or activity. The subject area to which the user Domain
applies a program is the domain of the software.
A system of abstractions that describes

Model selected aspects of a domain and can be used
to solve problems related to that domain.
There are just a few principles, but the domain-driven design is more
difficult to grasp since it involves a lot of storytelling, philosophy, and
case studies of various real-world challenges to provide some sort of
solution to them.
To allow the fluent sharing of knowledge, Domain-Driven Design calls
for the cultivation of a shared, business-oriented language: Ubiquitous
Language. This language should resemble the business domain and its
terms, entities, and processes—the communication vehicle mentioned
above.
Defining a Ubiquitous Language is not a trivial thing because the defined
terms can have different meanings in different contexts. To overcome this
hurdle, another Domain-Driven Design concept
is employed: the Bounded Context.
Domain
Ubiquitous
Sales Context
Language
Bounded
Context
Figure 1 Ubiquitous Language [5]
For example, if the accounting department needs some functionality

implemented, everyone must have the same understanding of accounting
concepts. As a result, a balance sheet and other accounting concepts
should have the same meaning for both domain experts and technical
individuals. Similarly, the specific wording in the warehousing department
must be known. As programmers, aside from the specific knowledge area
vocabulary, we also need to know what business rules, constraints, and
validations we should implement.
The Bounded Context concept was introduced to isolate specific areas
of the business from each other, all together constituting what is called a
Domain. So, if we’re dealing with accounting, we’re going to have concepts
like Customer, Product, and so on. Even though a Customer could be found
in Orders or Sales, the details related to it in these contexts may differ from
the details of the Customer in the Accounting context. In conclusion, there
are some differences, and it’s important to isolate specific parts of the
functionality in what is called, maybe in a not-so-self-explanatory manner,
Bounded Context.
So, think of Bounded Context as an isolated sandbox that will contain
specific parts of the domain knowledge and that will not interfere with
other sandboxes. Within this sandbox, language specific to that particular
business area is defined—a specific Ubiquitous Language. Outside of this
sandbox, the Ubiquitous Language’s terms may have different meanings.
Context Maps are basically a way of describing how information can be
exchanged between two sandboxes, such as Accounting and Sales, that
both refer to a specific Customer. For example, because the two definitions
of the same concept are incompatible, we would not be able to access a
Sales Customer with different attributes than an Accounting Customer.
Context Maps serve to create some adapters on both sides while keeping
the Customer concept unchanged on both sandboxes.
Domain
Sales Bounded
Context Context
ap Upstream
t M
tex
n
Downstream Co
Bounded Customer
Context Context
Figure 2 Context Maps [5]
An Upstream context will influence the Downstream counterpart,

while the opposite might not be true. This might apply to code (libraries
depending on one another) but also to less technical factors such as
schedule or responsiveness to external requests.
We’ll almost certainly need some kind of safeguard for the downstream
context in order to maintain its conceptual integrity against changes in
the upstream one. DDD identifies a number of organizational patterns
that can be used to describe and/or manage the interactions between
various contexts. The best pattern for this is called “Anti-Corruption
Layer” (ACL) [6], and it requires an explicit translation between the
two contexts at the code level, or better yet, at the context’s external
boundary [7].
Domain-Driven Design revolves around the idea of solving an
organization’s problems through code. This is achieved by focusing
the investment of resources at the heart of the business logic of the
application.
The Domain refers to the world of the business we’re working with and
the issues they’re trying to solve. This usually entails rules, processes,
and existing systems that must be integrated into your solution. So, to put
it another way, the Domain is the problem we’ll have to solve.
Within the context of most businesses, there will be terms that have
specific meanings. They’ll almost certainly have metrics, goals, and
objectives that are specific to their industry. The Domain of your project
will be made up of all of your knowledge about the company and how it
operates.
The Model of a Domain-Driven Designed project is your solution to a
specific problem; it’s how we’d approach what the business is trying to
solve by hiring us as technical experts and developers.
So, after discussion rounds, after we’ve defined the common language (or
ubiquitous language, as it’s known in Domain-Driven Design), and after
we’ve gained enough knowledge about the specific domain area to be
able to implement what the business requires, the Model is what we’ll
come up with.
The Model usually represents an aspect of reality or something of

interest. Often, it is also a simplification of the bigger picture, focusing
on the important aspects of the solution and ignoring everything else.
This means that the Model should be focused on the knowledge around a
specific problem that is simplified and structured to provide a solution.
Domain-Driven
Design Patterns
CSR report 2021 24

Now, let’s discuss the Domain-Driven Design Patterns in correlation with
the Building Blocks. The most common ones are [4]:
• Entity – an object that is not defined by its attributes, but rather by

its identity. Its state can change over time.
• Value Object – an object that is defined only by its state, and has
no identity. Such objects should be treated as immutable.
• Aggregate – a collection of entities or value objects that are

related to each other through an Aggregate Root object.
• Aggregate Root – owns an Aggregate (it’s the main object) and

serves as a gateway for all the changes within the Aggregate.
• Domain Event – an immutable domain object that defines an

event (something that has already happened) about which other domain
parts could be interested in reacting.
• Domain Service – when an operation does not conceptually

belong to any object it can be implemented in a service.
• Repository – the methods for retrieving domain objects should be

delegated to a specialized Repository object.
• Factory – the methods for creating domain objects should

be delegated to a specialized Factory object so that alternative
implementations may be easily interchanged.
The diagram below provides an overview of the key
domain-driven design concepts:
push state change with
Repositories
Domain Domain
Services Events access with access with
encapsulate with
act as root of
Entities
express model with Aggregates
express model with
express model with encapsulate with
encapsulate with
Model-Driven express model with Value
Design Objects encapsulate with
isolate domain encapsulate with

model gives with
structure to Factories
Layered
Architecture
define model
Ubiquitous with
Language
keep model
names unified by Continuous
enter
Integration Tactical Design
Bounded
Context
overlap allied
context through
Shared
Kernel
assess / overview
relationships with relate allied
context as
Context Customer /
Map overlap Supplier Teams
unilaterally as
Strategic Design
segregate the
conceptual messes
support multiple Conformist

translate and insulate clients through
unilaterally with
free teams
to go
Open Host
Big Ball Service Published
of Mud Anticorruption Separate formalize as
Ways Language
Layer
Figure 3 Domain-Driven Design landscape [9]
The E-Commerce
Domain-Driven
Designed Sample
In this chapter, we’ll provide a high-level overview of the concepts behind
a sample e-commerce solution. Before applying Domain-Driven Design,
the Domain of such a system might look like this UML Package diagram
[10, 11]:
Figure 4 High Level E-Commerce sample Domain [11]
Let’s start applying Domain-Driven Design to this sample Domain:
1. Identify the possible sub-domains inside a Domain (the “problem” to
solve). A Domain has its own strategic challenges which can be seen as
sub-domains that can be classified as Core, Support and Generic.
2. Split the Domain in sub-domains. It is a good practice to set a
Bounded Context for each sub-domain.
The result [11]:
Figure 5 High Level E-Commerce sample Domain, DDD [11]
On the previous UML Package diagram, the identified Bounded Contexts

are classified (using stereotypes) as Core, Support and Generic.
Usually, there is only one Core, that represents the main part of the
Domain—the Product Catalog.
The Support Bounded Contexts are auxiliary ones. They will support the
Core, but they will have their own model.
Generic Bounded Contexts are similar to Support ones, but they have a
strong particularity: they are pretty generic so that they can be used not
only in the domain where they were created, but they can be used by
other domains, too.
• Identify User Stories – identify the user stories (the backlog
grooming) following the role-feature-benefit pattern (or template) [13]:
As a [type of user], I want [an action], so that [a benefit/value]
• Identify the Nouns in the user stories -> Entities – the nouns
will become the main objects, not attributes. Just to enumerate few of
them in the context of the E-Commerce sample: Customer, Item, Order,
Shopping Cart
• Identify the Verbs in the user stories -> Behavior – in the same
context, these can be Add items to the Shopping Cart, Specify delivery
address, and many others
• Identify object interaction (UML diagram) [14]
Figure 6 The object interaction diagram
• Identify object responsibilities (UML diagram) [14]
Figure 7 The object responsibilities diagram
• Create the UML class diagram (only the main relationships)
Figure 8 Class diagram
For an example of how these concepts can be materialized into source

files, you can have a look at my GitHub repository:
https://github.com/AbstractSoft/eCommerce/tree/main/eCommerce.
Domain
The proposed architectural pattern for this type of solution is called
“Clean Architecture”. This name was coined by Robert “Uncle Bob”
Martin in his book “Clean Architecture: A Craftsman’s Guide to Software
Structure and Design”. This pattern is not totally new, it has evolved
over time from several other architectural patterns like Hexagonal
Architecture (or ports and adapters pattern) proposed by Alistair
Cockburn in 2005, and Onion Architecture created by Jeffrey Palermo in
2008.
This architectural pattern has a number of principles that I’ll summarize

here:
• Independent of Frameworks – the architecture does not depend
on the existence of some library. This allows you to use such frameworks
as tools, rather than having to cram your system into their limited
constraints.
• Testable – the business rules can be tested without the UI,

Database, Web Server, or any other external element.
• Independent of UI – the UI can change easily, without changing

the rest of the system. A Web UI could be replaced with a console UI, for
example, without changing the business rules.
• Independent of Database – you can swap out Oracle or SQL

Server, for Mongo, BigTable, CouchDB, or something else. Your business
rules are not bound to the database.
• Independent of any external agency (3rd parties) – in fact your

business rules simply don’t know anything at all about the outside world.
Clean Architecture Building Blocks [15]
Below are the most common graphical representations of this concept:
Figure 9 Original view
Figure 10 An alternative view
The layers of this architectural pattern, as they’re depicted above, are:
• Entities – encapsulate enterprise-wide domain entities that could

be used by many different applications in the enterprise.
• Use Cases – contain application specific business rules. They

orchestrate the flow of data to and from the Entities.
• Interface Adapters – convert data from the format most

convenient for the Use Cases and Entities, to the format most convenient
for some external agency such as the Database or the Web.
• Frameworks and Drivers – the outermost layer is generally

composed of frameworks and tools such as the Database, the Web
Framework, etc.
The above views are pretty abstract, and it’s hard to figure out how, as
developers, this architectural pattern can be applied to real-life projects.
That’s why a more down-to-earth approach really helps to get a better
understanding of what to do [17]:
Figure 11 Clean Architecture down to earth view
Let’s see what each layer is responsible for:
• Application Layer
o Implements use cases
o High-level application logic
o Knows about Domain, but no other layers
o Implemented using the CQS [18] pattern for simple scenarios; for
complex ones, the CQRS [19] pattern can be used
• Domain Layer
o Contains the Domain core Model
o No knowledge of other layers
o Independent of frameworks (no attributes or decorations)
o Beware of Anemic Domain Model antipattern [20]
• Persistence Layer
o Refers to Repository [21] pattern incarnations; the data source can
be anything from a relational database to a REST API
o Depends on Domain and is invoked by Application only
o Acts as a Mediator [22] between Domain and storage-specific entities
• Infrastructure Layer
o Facilitates the interaction with external systems and/or services
o Is invoked by Application only
o Can have a dependency on Domain, and can act as a Mediator [22]
between Domain and infrastructure specific entities
• Cross-Cutting Concerns
o Contains functionality used by more than one layer like Logging,
Exception Handling, Services Events, etc.
For an example of how the Clean Architecture and Domain-Driven Design

can be materialized into source files, you can have a look at my GitHub
repository: https://github.com/AbstractSoft/eCommerce
Conclusions
Patterns: Domain-Driven Design gives software developers the
principles and patterns to solve tough problems in software and, at times,
in business
Business Logic: Domain-Driven Design creates business logic by

explaining requirements from a domain knowledge perspective.
Successful History: Domain-Driven Design has a track record

of success with complex projects, which aligns with the experience
of software developers and the software applications that have been
developed.
On requirements and modeling:

Don’t start doing anything until you have requirements.
Don’t jump straight into the code as soon as you have requirements; put
together object interaction and responsibilities diagrams first.
When you have identified your objects, interactions and responsibilities,
use UML class diagrams to put together a draft model.
Don’t try to model the reality of the world, model the

reality of your organization—different companies will
have different approaches. Remember, it is all about your
business domain and not the actual “reality”.
References
1. https://en.wikipedia.org/wiki/Single-responsibility_principle
2. https://en.wikipedia.org/wiki/Anemic_domain_model
3. https://en.wikipedia.org/wiki/Separation_of_concerns
4. https://en.wikipedia.org/wiki/Domain-driven_design
5. https://thedomaindrivendesign.io/
6. https://dev.to/asarnaout/the-anti-corruption-layer-pattern-pcd
7. https://www.infoq.com/articles/ddd-contextmapping/
8. https://www.culttt.com/2014/11/12/domain-model-domain-driven-
design/
9. https://blog.jannikwempe.com/domain-driven-design-entities-value-
objects
10. https://www.uml-diagrams.org/package-diagrams-overview.html
11. http://www.fabriciosuarte.com/2016/02/domain-driven-design-
hands-on-example.html
12. http://www.zankavtaskin.com/2014/12/applied-domain-driven-
design-ddd-part-0.html
13. https://www.digite.com/agile/user-stories/
14. https://www.tutorialspoint.com/uml/uml_object_diagram.htm
15. https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-
architecture.html
16. https://www.freecodecamp.org/news/a-quick-introduction-to-clean-
architecture-990c014448d2/
17. https://matthewrenze.com/courses/clean-architecture-patterns-
practices-and-principles/
18. https://en.wikipedia.org/wiki/Command–query_separation
19. https://en.wikipedia.org/wiki/Command–query_
separation#Command_Query_Responsibility_Separation
20. https://www.martinfowler.com/bliki/AnemicDomainModel.html
21. https://www.martinfowler.com/eaaCatalog/repository.html
22. https://en.wikipedia.org/wiki/Mediator_pattern
+33 970754570
Pentalog, 1 rue des Hauts
45380 La Chapelle Saint-Mesmin
PENTALOG.COM

Pragmatic DDD Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pragmatic DDD Guide

Uploaded by

Copyright:

Available Formats

DOMAIN-DRIVEN

WHY DO WE NEED DOMAIN-DRIVEN DESIGN? ................................

DOMAIN-DRIVEN DESIGN BUILDING BLOCKS ................................

Bounded Context / Context Maps ................................................................................

Domain [8] ....................................................................................................................

Model [8] ....................................................................................................................... 23

DOMAIN-DRIVEN DESIGN PATTERNS .............................................

THE E-COMMERCE DOMAIN-DRIVEN DESIGNED SAMPLE ............... 27

Requirements and Modelling [12] ...............................................................................

The Software Architecture ..........................................................................................

FIGURE 1 UBIQUITOUS LANGUAGE [5] ............................................ 10

FIGURE 2 CONTEXT MAPS [5] .......................................................... 11

FIGURE 3 DOMAIN-DRIVEN DESIGN LANDSCAPE [9] ...................... 13

FIGURE 4 HIGH LEVEL E-COMMERCE SAMPLE DOMAIN [11] ........... 14

FIGURE 5 HIGH LEVEL E-COMMERCE SAMPLE DOMAIN, DDD [11] .. 14

FIGURE 6 THE OBJECT INTERACTION DIAGRAM ............................. 15

FIGURE 7 THE OBJECT RESPONSIBILITIES DIAGRAM .................... 16

FIGURE 8 CLASS DIAGRAM ............................................................. 17

FIGURE 9 ORIGINAL VIEW .............................................................. 18

FIGURE 10 AN ALTERNATIVE VIEW ................................................. 19

FIGURE 11 CLEAN ARCHITECTURE DOWN TO EARTH VIEW ............ 20

Almost all of us have experienced, or still

In some cases. Of course, we are going to

3 Sometimes there are misunderstandings

Changes are sometimes difficult due to the 4

Usually, there is a tight coupling between

7 Related to violations of software design

As software developers, we need to “translate” the real-world business

Domain-Driven Design favors the Separation of Concerns (SoC) design

Typically, a complex problem may be broken down into smaller problems

• Employing a domain model to facilitate creating complex designs.

• Establishing a collaborative effort between technical and domain

This implies that almost everything in the

Requirements are always explained from

The main disadvantage of introducing

The purpose of Domain-Driven Design is to

A high level of isolation and encapsulation

The language that the technical team will

A sphere of knowledge (ontology), influence,

A system of abstractions that describes

Figure 1 Ubiquitous Language [5]

For example, if the accounting department needs some functionality

Figure 2 Context Maps [5]

An Upstream context will influence the Downstream counterpart,

The Model usually represents an aspect of reality or something of

CSR report 2021 24

• Entity – an object that is not defined by its attributes, but rather by

• Aggregate – a collection of entities or value objects that are

• Aggregate Root – owns an Aggregate (it’s the main object) and

• Domain Event – an immutable domain object that defines an

• Domain Service – when an operation does not conceptually

• Repository – the methods for retrieving domain objects should be

• Factory – the methods for creating domain objects should

push state change with

isolate domain encapsulate with

support multiple Conformist

Figure 3 Domain-Driven Design landscape [9]

Figure 4 High Level E-Commerce sample Domain [11]

The result [11]:

Figure 5 High Level E-Commerce sample Domain, DDD [11]

On the previous UML Package diagram, the identified Bounded Contexts

• Identify object interaction (UML diagram) [14]

Figure 7 The object responsibilities diagram