Seminar - Scalable Enterprise Application Development Using DDD and CQRS
Download as pptx, pdf1 like496 views
This document discusses domain-driven design (DDD) and command query responsibility segregation (CQRS). It provides an overview of key DDD concepts like the domain model, bounded contexts, entities, value objects, aggregates and ubiquitous language. It also covers benefits and drawbacks of DDD. CQRS is introduced as separating commands and queries, with commands modifying data and events being published, while queries read data from multiple read models optimized for different use cases. The document provides examples of using these techniques for scalable enterprise application development.
More Related Content
Similar to Seminar - Scalable Enterprise Application Development Using DDD and CQRS (20)
Seminar - Scalable Enterprise Application Development Using DDD and CQRS
- 1. Scalable Enterprise Application Development Using DDD and CQRS - Mizanur Rahman Sarker
- 2. Topics DDD CQRS Demo
- 3. 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.
- 4. 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
- 5. 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
- 6. 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.
- 7. Elements of Domain Model Domain Sub Domain Bounded Context Ubiquitous Language Entity Value Object Domain Service Domain events Aggregates
- 9. 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
- 10. Sub Domain Core domain Supporting domain Generic Domain
- 11. Sub Domain Each subdomain is separate Implementation of sub domain is completely independent
- 12. Sub Domain DDD is designed for complex domain It’s not a good idea to use for simple application
- 13. 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.
- 14. Bounded Context
- 15. 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.
- 16. 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.
- 17. Entity Defined by there identity Should be able to track, locate, retrieve and store Product Id Name
- 18. 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
- 19. 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
- 20. 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;} }
- 21. It’s better to have logic in value objects It’s almost no side effect
- 22. 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
- 23. Aggregates Aggregates Aggregate Roots Invariants
- 24. 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
- 25. 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
- 28. Invariants Is a condition should always be true Number of items should not exceed the maximum number of items
- 29. “An Aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes” Eric Evals
- 31. Only aggregate roots can be reference outside aggregate group Aggregate and Aggregates only applies to objects not data
- 33. 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
- 34. Repository Think of it as an in-memory collection Add, Remove, Retrieve Can grab data from database, file system etc
- 35. Domain Events and Anti Corruption Layers Domain Events Anti-Corruption Layers
- 36. 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
- 37. Events Something occur Button click events
- 39. 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
- 40. 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
- 41. Domain Event Boundaries Create Separate event objects for specific clients Create cross-system events for external clients User bus for other domain
- 42. 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
- 43. CQRS CQRS stands for Command Query Responsibility Segregation Command Query
- 44. 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.
- 45. 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.
- 46. 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().
- 47. 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.
- 48. Service Bus Nservice Bus
- 49. Logging Logging is very important in distributed application
- 50. Demo Sales Stock Mgmt Customer Mgmt Red o Read Model Write Model Read Model Write Model Read Model Write Model Infrastructure/Shared Kernel
- 51. Query Server Commands Events Dto Denormalizer Server Command Handler Read Model Write Model Event Handler Domain
- 52. Thank You