(Clean Architecture) Commands and Queries (CQRS)

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 네번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Commands and Queries

CQRS Architectures

Pros and Cons

Command-Query Separation

Command

Does something

Should modify state

Should not return a value

Query

Answers a question

Should not modify state

Should return a value

Command-Query separation is a good idea, but not always possible.

e.g. Pop a stack (Remove item - command, Return top item - query)

e.g. Create a new record (Create record - command, Return new ID - query)

So in general we should strive to maintain command query separation where possible.

Command Query Responsibility Separation(CQRS) Architecture

Expand command query separation to the architectural level.

Dividing the architecture into a command stack, and a query stack, starting at the application layer. Because queries should be optimized for reading data, whereas commands should be optimized for writing data. 

Command execute behaviors in the domain model, mutate state, raise event, and write to the database.

Queries use whatever means is most suitable to retrieve data from the database, project it into a format for presentation, and display it to the user.

This change increases both the performance of the commands and queries, but equally important, it increases the clarity of the respective code. CQRS is domain-centric architecture done in a smart way

Three types of CQRS Architecture

Single-database CQRS : Commands use domain, Queries use database (Simplest)

Two-database CQRS : Read and writhe databases, Commands use write DB, Queries use read DB, Eventual consistency between databases, Orders of magnitude faster

Event Sourcing CQRS : do not store the current state of our entities in a normalized data store. Store events (store historical record of all events in a persistence medium called an event store. Replay events. Modify entity. Store new event. Update read database.

Complete audit trail, Point-in-time reconstruction, Replay events(good for debugging and testing), Multiple read database, Rebuild production database.

Why Use CQRS?

Pros

More efficient design

Optimized performance

Event sourcing benefits

Cons

Inconsistent across stacks

More complex

Event sourcing costs

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 네번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.