seminar - scalable enterprise application development using ddd and cqrs
Post on 15-Apr-2017
320 Views
Preview:
TRANSCRIPT
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
top related