Scribd
Upload
5 views30 pages

Simplifying The Read Model Slides

simplifying-the-read-model-slides

Uploaded by

lounes.lou20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views30 pages

Simplifying The Read Model Slides

simplifying-the-read-model-slides

Uploaded by

lounes.lou20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 30

Simplifying the Read Model

Vladimir Khorikov

@vkhorikov www.enterprisecraftsmanship.com
Agenda

Commands,
queries,
handlers,
and
decorators
Agenda

Simplicity

Performance

Scalability
Agenda

Commands,
queries, Simplifying
handlers, the read
and model
decorators
The State of the Read Model

Command model Query model

Write model Read model

Write side Read side

Command side Query side

Writes Reads
Separation of the Domain Model

How to fix the


performance issues?
Separation of the Domain Model

CQRS

Writes Reads

Optimizing decisions for


different situations
Separation of the Domain Model

App
API
services

Client App Domain


API
services model
App
API
services
Database

Split the Update API

Introduced explicit command


and query handlers
Separation of the Domain Model

Same domain model


for reads and writes

Domain model
overcomplication

Bad query performance


Separation of the Domain Model

A complex domain model that


handles neither reads nor writes well

Make the difference between


reads and writes explicit

Split the domain model


Separation of the Domain Model

Are we going to have


two domain models
now?

Take the domain model


out of the read side
Separation of the Domain Model
DDD goes here

Commands

Client Create

Queries

Database
Server
Not here

No need in encapsulation
No data modifications = No need in abstractions
Recap: Simplifying the Read Model

Simplified the read side

Read model is a thin wrapper


on top of the database

Can use database-specific features


to optimize the performance
Recap: Simplifying the Read Model

Encapsulation Read side

Data changes are


No data changes
consistent

All invariants are No need in


met encapsulation

No need in DDD
Recap: Simplifying the Read Model

DDD lives here

Commands

Client Create

Queries

Database
Server
Thin wrapper on
top of the DB
Recap: Simplifying the Read Model

Complex SQL
queries

Vendor-specific
Queries
features

Stored
procedures
Recap: Simplifying the Read Model

Doesn’t it make the


read model anemic?

There’s no need in
encapsulation if you
don't modify any data
Recap: Simplifying the Read Model

Optimized the data retrieval

Got rid of the N+1 problem


Recap: Simplifying the Read Model

ORM with enabled lazy


loading leads to N+1

Disable lazy loading

Not use such ORMs

Don't use the ORM


on the read side
CQRS allows you to optimize,
read and write models for the
different requirements.
Recap: Simplifying the Read Model

public class Student : Entity


{
public virtual string Name { get; set; }
public virtual string Email { get; set; }

private readonly IList<Enrollment> _enrollments = new List<Enrollment>();


public virtual IReadOnlyList<Enrollment> Enrollments => _enrollments.ToList();
public virtual Enrollment FirstEnrollment => GetEnrollment(0);
public virtual Enrollment SecondEnrollment => GetEnrollment(1);
}

Simplified the commands side too

The domain model focuses on commands only


Recap: Simplifying the Read Model
It is impossible to create an optimal solution for searching,
and processing of transactions utilizing a single model

Both reads and writes benefit from the separation

Writes benefit from removing code from the domain model


that is not used for data modifications

Reads benefit because you are able to optimize the data


retrieval

Use a “big” ORM in commands Use handwritten SQL in queries


Recap: Simplifying the Read Model

Simplicity

Performance

Scalability
The Read Model and the Onion Architecture
Entities
Aggregates
Value Objects
+ Commands and queries
Domain Events
Pure Domain
Services

Repositories
Impure Domain
Services

Application
Services
UI
The Read Model and the Onion Architecture

public sealed class GetListQuery : IQuery<List<StudentDto>>


{
public string EnrolledIn { get; }
public int? NumberOfCourses { get; }
}
The Read Model and the Onion Architecture
Entities
Aggregates
Value Objects
The query is here
Domain Events
Pure Domain
Services

Repositories
Impure Domain
Services

Application
Services DTOs go here
UI
The Read Model and the Onion Architecture

public sealed class GetListQuery : IQuery<List<StudentDto>>


{
public string EnrolledIn { get; }
public int? NumberOfCourses { get; }
}

public sealed class GetListQuery : IQuery<List<Student>>


{
public string EnrolledIn { get; }
public int? NumberOfCourses { get; }
}

Queries no longer reside in the onion


Simplifying the read model
- It no longer uses the domain model
- Doesn’t use NHibernate

Introduced the separation at the domain


model level
Summary - Simplified the command side
- Optimized the query side
- The domain model no longer contains
code used by the queries
- Can even get rid of repositories
- Can use database-specific features in
reads

There’s no need for encapsulation in the


reads

The read model and the onion architecture


- Queries are no longer part of the onion
In the Next Module

Introducing a Separate Database for


Queries

You might also like