DDD and CQRS Quick Overview

Domain-Driven Design and Command-Query Responsibility Segregation architectural patterns and how to implement them

Transcript

1. Domain Driven Design and Command Query Responsibility Segregation Ulugbek Miniyarov Customer Experience Engineering
2. Command Query Responsibility Segregation Mainstream approach: CRUD
3. Command Query Responsibility Segregation Split conceptual model into separate models for update and display - Command: for creating/updating/deleting - Query: for retrieving/reading
4. Command Query Responsibility Segregation
5. Command Query Responsibility Segregation CQRS naturally fits with - Task-based UI - Event-based architecture - Eventually consistent systems - Domain-Driven Design Benefits - High performance applications - Separate the load from reads and writes - Allows scaling/optimizing reads and writes independently
6. Command Query Responsibility Segregation When not to use - Many systems fit a CRUD mental model - CQRS is a significant mental leap, shouldn’t be tackled unless it’s worth - CQRS may add complexity to domain that doesn’t match, reducing productivity and increasing risk. - Still can use reporting database for excessive read queries rather than splitting read/writes
7. Command Query Responsibility Segregation References and further read: - https://martinfowler.com/bliki/CQRS.html - https://culttt.com/2015/01/14/command-query-responsibility-segregation-cqrs/
8. Demo & Real-World Usage!
9. Domain-Driven Design - Framework to tackle complex software projects - Centers the development on domain model that is rich with processes and rules of the domain - Is a set of patterns and common terminology - Is not a specific technology or programming language - Encompasses theoretical workflow not a concrete implementation - Introduced by Eric Evans
10. - Ubiquitous Language - Embeds domain terminology into software systems - A shared vocabulary between domain experts and developers - Model-Driven Design - a pattern to present elements of object models in software systems - Layered Architecture - Separation of concerns - In a software, large part of application is not related to the domain Domain-Driven Design
11. Model-Driven Design
12. Models expressed in Software Components of a model: - Entities - Objects that are not defined by their attributes - Distinguished objects from similar ones - Contains immutable unique identity irrespective of form, state, history, and other attributes - Value Objects - Immutable objects that are defined by their attributes - Services - Comes into play when some concepts of domain cannot be modeled as entity or VO - Provides functionality to the domain - Operations can refer to other domain objects - Operations are stateless
13. Lifecycle of a model - Aggregates - Associates multiple domain objects into a unit of work - Contains a root entity to be accessed from outside - Factories - Helps create an entity that has laborious construction process otherwise - Factory methods should be atomic - meaning all objects of an Aggregate must be created, avoiding undefined state - Repositories - Helps retrieve/reconstitute entities from archive/database
14. Layered Architecture A common architectural pattern for DDD: - User Interface - Presents info to the user and interprets use commands - Application Layer - A thin layer that coordinates application activity - Does not contain domain knowledge, delegates the work to domain layer - Domain Layer - The heart of the business. Contains info about the domain and its rules - Infrastructure Layer - Contains supporting libraries for other layers - Provides communication between layers - Implements persistence for business objects
15. Layer Policies - Layers are strongly cohesive - Layers depend on lower layers only - Loosely coupled - Communication with higher layers may use - Callbacks - Observer pattern - Shared objects
16. Domain-Driven Design References and further read: - Book by Eric Evans - Domain-Driven Design: Tackling Complexity in the Heart of Software - Domain-Driven Design Quickly - http://carfield.com.hk/document/software%2Bdesign/dddquickly.pdf
17. Demo & Real-World Usage!
18. THANK YOU