Clean Architecture & Design Patterns in Practice · บทเรียน

CQRS ภายในสถาปัตยกรรมสะอาด

เรียนรู้ว่า Command Query Responsibility Segregation แยกโมเดลการเขียนและการอ่านอย่างไร และแนวคิดนี้เข้ากับขอบเขตของสถาปัตยกรรมสะอาดได้อย่างไร

บทเรียน 4 จาก 413 ขั้นตอน

CQRS ภายในสถาปัตยกรรมสะอาด เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

One Model Doing Too Much

As systems grow, a single model that handles both writes and reads often strains.

Writes need rich validation and invariants; reads need fast, shaped data for screens. CQRS splits these concerns.

Commands vs Queries

CQRS divides operations into two kinds:

  • Commands change state and return nothing meaningful.
  • Queries return data and never change state.

This is the Command-Query Separation principle, scaled to architecture.

Separate Write and Read Models

The write side uses rich entities enforcing invariants. The read side uses simple, denormalized DTOs tailored to each view.

They can even use different storage, optimized for their job.

A Command

A command captures intent and is handled by a write-side interactor.

class PlaceOrderCommand {
    final String customerId;
    final java.util.List<String> items;
    PlaceOrderCommand(String c, java.util.List<String> i) {
        this.customerId = c; this.items = i;
    }
}

A Command Handler

The handler loads entities, enforces rules, and persists — pure use-case logic.

class PlaceOrderHandler {
    private final OrderRepository repo;
    PlaceOrderHandler(OrderRepository repo) { this.repo = repo; }
    void handle(PlaceOrderCommand cmd) {
        Order order = Order.create(cmd.customerId, cmd.items);
        repo.save(order);
    }
}

A Query

The read side bypasses rich entities and returns a shape built for display.

class OrderSummaryDto {
    public String orderId;
    public String status;
    public double total;
}
interface OrderQueries {
    OrderSummaryDto getSummary(String orderId);
}

How It Maps to Clean Architecture

Both sides honor the dependency rule:

  • Command handlers are interactors using repository output ports.
  • Query interfaces are also ports, implemented in the outer layer.

CQRS adds no new violation; it just doubles the use-case shape.

Optional: Eventual Consistency

In advanced setups the read model is built asynchronously from events emitted by the write side.

This brings eventual consistency: reads may briefly lag writes. Adopt it only when scale truly demands it.

When CQRS Pays Off

  • Read and write workloads differ dramatically.
  • Complex domains where write invariants clutter read queries.
  • High-read systems needing tailored projections.

For simple CRUD, plain repositories are enough.

The Cost Side

CQRS adds moving parts: two models, possibly two stores, and synchronization.

That complexity is justified only when the separation buys real clarity or performance. Do not adopt it by default.

A Pragmatic Middle Ground

You can apply logical CQRS without separate databases: just split command handlers from query services in code.

This captures most of the clarity benefit with little extra infrastructure.

Quick Check

Test your understanding of CQRS.

Recap

You learned CQRS within Clean Architecture.

  • Commands change state; queries read it.
  • Separate write (rich entities) and read (DTOs) models.
  • Both remain ports honoring the dependency rule; adopt it only when complexity warrants.
เริ่มต้นได้ฟรี

เรียนรู้ Clean Architecture & Design Patterns in Practice ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
12
บทเรียน
48

คำถามที่พบบ่อย

บทเรียน “CQRS ภายในสถาปัตยกรรมสะอาด” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “CQRS ภายในสถาปัตยกรรมสะอาด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “CQRS ภายในสถาปัตยกรรมสะอาด”

เรียนรู้ว่า Command Query Responsibility Segregation แยกโมเดลการเขียนและการอ่านอย่างไร และแนวคิดนี้เข้ากับขอบเขตของสถาปัตยกรรมสะอาดได้อย่างไร คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “CQRS ภายในสถาปัตยกรรมสะอาด” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม

ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การจัดการข้อกังวลที่ครอบคลุมหลายส่วน
  2. สถาปัตยกรรมสะอาดที่ขับเคลื่อนด้วยเหตุการณ์
  3. สถาปัตยกรรมสะอาดในไมโครเซอร์วิส
  4. CQRS ภายในสถาปัตยกรรมสะอาด
← กลับไปที่ Clean Architecture & Design Patterns in Practice