Scalable Enterprise Application Development Using DDD and CQRS- Mizanur Rahman Sarker

Topics

DDD CQRS Demo

DDD

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following: Placing the project's primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to

iteratively refine a conceptual model that addresses particular domain problems.

Benefits of DDD

Flexible Customer’s vision/perspective of the problem Path through a very complex problem Well-organized and easily tested code Business logic lives in one place Many great patterns to leverage

Drawbacks

Time and Effort Discuss & model the problem with domain experts

What is really core domain? How to separate from infrastructure code?

Isolate domain logic from other parts of applicatio Learning curve

New principles New patterns New Process

Only make sense when there is complexity in the problem

While Domain-driven Design provides many technical benefits, such as maintainability

It is recommended that it be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

Elements of Domain Model

Domain Sub Domain Bounded Context Ubiquitous Language Entity Value Object Domain Service Domain events Aggregates

Navigation Map

Domain

The Domain Layer is responsible for representing concepts od the business, information about the business situation and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure.

This layer is the heart of business While designing the domain it’s important to focus on the behavior of

the object rather than properties and attributes

Sub Domain

Core domain Supporting domain Generic Domain

Sub Domain

Each subdomain is separate Implementation of sub domain is completely independent

Sub Domain

DDD is designed for complex domain It’s not a good idea to use for simple application

Bounded Context

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Bounded Context

Sub Domains vs Bounded COntext

A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organization.  logistics and operations might be separated from invoicing & billing. Eric

differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.

Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain.

To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.

Ubiquitous Language

The concept is simple, that developers and the business should share a common language that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology. Wrong Language:

The length and width ratio of the smaller bed rooms would be 4:3.

Correct Language: The children's bed room’s length will be 20 ft and width will be 15 ft. Note that, to the owner of the building “smaller room”, “ratio” - all these things

could be very technical terms. Rather it is easier for him to understand children's room, guest room, living room etc. And explicit measurement is more meaningful to him.

Entity

Defined by there identity Should be able to track, locate, retrieve and store

Product Id Name

Entity

Anemic Domain Focus on state of an object Bags of getters and setters No domain model in domain object Instead have services for that

Rich Domain model Behavior Validation

Value Object

Measures, quantifies or describes a thing in the domain Identity is based on composition of values Immutable

Should not be able to change after created Compared using all values No side effects

Value Object

String is a value object “Car”, “Cat”

Money $50000000 USD or Australian $

Worth, DateTimeRange Public class DateTimeRange{public DateTimeRange(DateTime start, DateTime end)this.Start = start;this.End = end

}Public DateTime Start{get; private set}Public DateTime End{get; private set;}}

It’s better to have logic in value objects It’s almost no side effect

Domain Service

Important Operations that don’t belong to a particular entity or value object

Operations on multiple domain entity Processing an order might involve multiple of entities

Good Domain Services: Not a natural part of an entity or value object Have an interface defined in terms of other domain model elements Are stateless (but may have side effects)

Should be able to create a new one without depending on previous result

Aggregates

Aggregates Aggregate Roots Invariants

Aggregates

Tackling Data complexity Eliminating bi-deirectional relations

Let, you have an object with 100 object related with that in entity framework

Now if you save it have to track with all others

Aggregates

Aggregate consists of one or more entities and value objects that change together

Need to consider them as an unit for data changes We need to consider the entire consistency before apply changes

Invariants

Is a condition should always be true Number of items should not exceed the maximum number of items

“An Aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes” Eric Evals

Only aggregate roots can be reference outside aggregate group Aggregate and Aggregates only applies to objects not data

Aggregate Tips

Aggregates exist to reduce complexity You might not always need an aggregate Don’t add aggregate just for the sake of using aggregate Entities within an aggregate can only reference to root entity But you can always use foreign key values for non root entities Aggregate of one is always possible Rule of cascading delete

If not, may be you have wrong structure for aggregate

Repository

Think of it as an in-memory collection Add, Remove, Retrieve Can grab data from database, file system etc

Domain Events and Anti Corruption Layers Domain Events Anti-Corruption Layers

Domain Events

Critical part of bounded context They provide a way to describe important activities or state changes

that occurred in the system Then other part of the system can respond in a loosely coupled manner Entities, value objects aggregate all can raise events We can use domain events to communicate outside our domain Domain events should be full phased classes Domain events should be part of ubiquitous language

Events

Something occur Button click events

Domain events is something that happens So, it’s immutable It’s not possible to change like history To change this you have to do another event

Designing Domain Events

Each event is its own class Include when the event took place(Time) Capture event specific details Event fields are initialized in constructor No behavior or side effects

Domain Event Boundaries

Create Separate event objects for specific clients Create cross-system events for external clients

User bus for other domain

Anti-corruption layer

It’s helps to prevent corruption in your domain model Translate between foreign system models to our own Façade, Adapter, Custom translation

CQRS

CQRS stands for Command Query Responsibility Segregation Command Query

CQRS

A Message is the unit of communication for NServiceBus. There are two sub-types of messages that capture more of the intent and help NServiceBus enforce messaging best practices. This enforcement is enabled by default unless disabled inconfiguration.

Command

Used to request that an action should be taken. A Command is intended to be sent to a receiver (all commands should have one logical owner and should be sent to the endpoint responsible for processing). As such, commands ...

are not allowed to be published. cannot be subscribed to or unsubscribed from. cannot implement IEvent.

Event

Used to communicate that some action has taken place. An Event should be published. An event ...

can be subscribed to and unsubscribed from. cannot be sent using Bus.Send() (since all events should be published). cannot implement ICommand. cannot be sent using the gateway, i.e., bus.SendToSites().

For reply messages in a request and response pattern, you may want to use IMessage since these replies are neither a Command nor an Event.

The simplest way to define a message is to use marker interfaces. NServiceBus.IMessage for defining a Message. NServiceBus.ICommand for defining a Command. NServiceBus.IEvent for defining an Event.

Service Bus

Nservice Bus

Logging

Logging is very important in distributed application

Demo

Sales Stock Mgmt Customer MgmtRed odel

Read Model

Write Model

Read Model

Write Model

Read Model

Write Model

Infrastructure/Shared Kernel

Query Server

Commands Events Dto

Denormalizer Server

Command Handler

Read Model Write Model

Event Handler

Domain

Thank You