TRAINING CENTER

Domain Driven Design

Module 5
Strategic Design meets Implementation
 D o m a i n D r i v e n D e s i g n

Module Overview

Persistence and Event Sourcing

CQRS (Command Query Responsibility Segregation)

Integrating Bounded Contexts

1
 D o m a i n D r i v e n D e s i g n

Persistence and Event Sourcing…

“Persistence and event sourcing are two important concepts in the context of
domain-driven design (DDD). They provide approaches for designing and
implementing robust, scalable, and maintainable software systems.”

“Persistence refers to the mechanism of storing and retrieving domain objects to

and from a persistent storage medium, such as a database. In DDD, the goal of
persistence is to ensure that the state of domain objects is preserved over time,
allowing them to be reloaded and manipulated as needed. To achieve this,
persistence is typically implemented using an Object-Relational Mapping (ORM)
framework or directly with a database access layer.”

2
 D o m a i n D r i v e n D e s i g n

…Persistence and Event Sourcing…

“Event sourcing, on the other hand, is a pattern that focuses on capturing and
storing the full history of changes (events) that occur within a system. Instead of
persisting only the current state of an object, event sourcing persists a sequence of
events that have led to the current state. These events are typically stored in an
append-only log, known as the event store. By replaying these events, the system
can reconstruct any past state of an object, providing a complete audit trail and
enabling temporal querying.”

3
 D o m a i n D r i v e n D e s i g n

…Persistence and Event Sourcing…

When applied together, persistence and event sourcing can bring several benefits to
a DDD-based system: Scalability and concurrency: Since
Temporal querying: By replaying
Historical transparency: Event events are append-only, event
events, it becomes possible to query
sourcing captures the full history of sourcing can provide excellent write
the system at any point in time. This
changes, enabling the system to scalability and concurrency, as there
capability is particularly valuable
provide a detailed audit trail. This can are no contention issues when
when dealing with temporal data, as
be useful for debugging, compliance, multiple components or users update
it allows for historical analysis and
and forensic analysis. different parts of the system
reporting.
simultaneously.

Evolving business rules: With event

Collaboration and bounded contexts:
sourcing, it is possible to introduce
Event sourcing encourages the
new business rules or modify existing
exploration of bounded contexts
ones by projecting events into
within a domain. Different teams can
different read models or
focus on specific events and project
transforming events into new
them into their own read models,
representations. This flexibility allows
fostering better collaboration and
for system evolution without
autonomy.
breaking existing data structures.

4
 D o m a i n D r i v e n D e s i g n

However

“However, it's important to note that implementing persistence and event sourcing
requires careful design and consideration. It introduces complexity and additional
challenges, such as managing event versioning, snapshotting, and dealing with long-
running processes. Therefore, it is crucial to assess the trade-offs and determine if
the benefits outweigh the costs for a particular system before adopting these
approaches.”

5
 D o m a i n D r i v e n D e s i g n

CQRS (Command Query Responsibility Segregation)…

“CQRS (Command Query Responsibility Segregation) is a pattern that aligns well

with the principles of domain-driven design (DDD) and addresses the separation of
concerns in handling read and write operations in a software system. It introduces a
clear distinction between the responsibilities of commands (changes to the system's
state) and queries (retrieval of data).”

6
 D o m a i n D r i v e n D e s i g n

…CQRS (Command Query Responsibility Segregation)…

“In traditional systems, a single model is often used to handle both commands and
queries. However, as systems grow in complexity, the requirements for reading and
writing data may diverge. CQRS advocates for splitting the read and write concerns
into separate models, providing more flexibility, scalability, and performance
optimizations.”

7
 D o m a i n D r i v e n D e s i g n

…Persistence and Event Sourcing…

Here are some key aspects of CQRS:

Separate models: CQRS Asynchronous Performance Scalability: CQRS allows for Domain-centric design: Event sourcing integration:
suggests having distinct communication: CQRS optimizations: since the independent scalability of CQRS aligns with DDD by CQRS and event sourcing
models for read operations often relies on read and write models are the read and write emphasizing a domain- often go hand in hand.
(query model) and write asynchronous separated, each can be components. As read centric design approach. It Event sourcing can be used
operations (command communication between optimized independently. operations tend to be more enables developers to to capture the changes
model). The query model the command and query The query model can be frequent than writes, the model the system based on made through commands,
focuses on providing models. Commands are tuned for read-intensive query model can be scaled the distinct command and and the resulting events
efficient data retrieval and sent to the command operations, leveraging independently to handle query requirements of the can be projected into the
is often denormalized and model and processed caching, precomputing, increased read traffic business domain, leading query model, ensuring that
optimized for specific read asynchronously, typically and indexing techniques. without impacting the to a better representation the query model is up-to-
use cases. The command through a message queue The command model can write operations. of the domain concepts date with the latest
model handles the write or event bus. The results of focus on enforcing business and their behavior. changes in the system.
operations and enforces write operations are then rules without the
business rules, ensuring propagated to the query performance
consistency and integrity. model, ensuring eventual considerations of data
consistency. retrieval.

8
 D o m a i n D r i v e n D e s i g n

CQRS (Command Query Responsibility Segregation)…

“CQRS can be a powerful pattern for systems with complex and evolving read and
write requirements. However, it introduces additional complexity and requires
careful design considerations, as it involves managing the synchronization between
the command and query models and handling eventual consistency. It is essential to
evaluate the trade-offs and ensure that the benefits of CQRS align with the specific
needs of the system before adopting it.”

9
 D o m a i n D r i v e n D e s i g n

Integrating Bounded Contexts…

“Integrating bounded contexts is a critical aspect of domain-driven design (DDD)

that focuses on how different parts of a system, represented as bounded contexts,
can interact and collaborate with each other effectively. Bounded contexts are
cohesive units within a domain where concepts, language, and rules are consistent.”

10
 D o m a i n D r i v e n D e s i g n

… Integrating Bounded Contexts…

Here are some considerations for integrating bounded contexts in DDD:

Shared Kernel: When Context Mapping: Anti-Corruption Layer: Shared Language: Integration Events: Context-specific APIs: Continuous
two or more bounded Context mapping is a An anti-corruption Establishing a shared Integration events, also To facilitate the Collaboration:
contexts need to technique for defining layer is a mechanism language between known as domain integration between Integrating bounded
collaborate closely, a the relationships and used to protect a different bounded events or system bounded contexts, contexts is an ongoing
shared kernel can be boundaries between bounded context from contexts is crucial for events, are context-specific APIs process that requires
established. The shared bounded contexts. It the complexities and effective collaboration. notifications that can be designed. These continuous
kernel defines a subset helps identify the types constraints of another Each context should capture meaningful APIs provide a well- collaboration between
of the domain model of interactions context with a different have its own occurrences within a defined interface that teams working on
and language that is between contexts and model or language. It ubiquitous language bounded context. allows external different contexts.
shared between the provides strategies for acts as a translation that is well understood These events can be contexts to interact Regular
bounded contexts. This handling these layer, transforming within its boundaries. used to communicate with a bounded communication,
allows for a common interactions. Context requests and responses However, when changes or important context. By exposing knowledge sharing,
understanding and mapping techniques between the two interacting with other information to other only the necessary and alignment on the
communication include defining contexts, ensuring that contexts, a shared contexts. By publishing operations and evolving domain model
between teams explicit boundaries, the internal model of language should be integration events, a encapsulating the are crucial to ensure a
working on different creating partnership each context remains established to bridge context can internal complexities, cohesive system design
contexts. agreements, and clean and unaffected the communication communicate its state the APIs enable and effective
establishing translation by the other. gap and align the changes or decisions to controlled access and integration.
layers to bridge the understanding of other contexts communication
semantic gaps between concepts and terms. asynchronously, between contexts.
contexts. facilitating loose
coupling and 11
decoupled integration.
 D o m a i n D r i v e n D e s i g n

… Integrating Bounded Contexts

By carefully considering and applying these integration techniques, DDD enables

the development of well-structured, modular, and maintainable systems that can
evolve and scale over time while preserving the integrity of each bounded context.

12
Who else needs
some coffee ?
Domain Driven Design

13
• Mod_TR_019_R2_0118

Technical Training
Let’s do it

14