Domain Driven Design and Command Query Responsibility Segregation Ulugbek Miniyarov Customer Experience Engineering

Command Query Responsibility Segregation Mainstream approach: CRUD

Command Query Responsibility Segregation Split conceptual model into separate models for update and display - Command: for creating/updating/deleting - Query: for retrieving/reading

Command Query Responsibility Segregation

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

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

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/

Demo & Real-World Usage!

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

- 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

Model-Driven Design

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

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

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

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

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

Demo & Real-World Usage!

THANK YOU