Belajar Software Architecture and Design Patterns - CQRS (Command Query Responsibility Segregation) | Belajar Software Architecture and Design Patterns

#Pendahuluan

Perhatikan kebohongan arsitektur yang biasa: model yang dioptimalkan untuk menulis (normalisasi, invarian ketat) dipaksa melayani pembacaan (query kompleks, laporan, agregasi). CQRS mengakui kenyataan itu: jalur menulis dan membaca punya kebutuhan berbeda — jadi pisahkan mereka.

#Konsep

#Write Model & Read Model

100%

Command: perintah yang MENGUBAH state, punya nama imperatif (PlaceOrder), divalidasi terhadap invarian, return minim.
Query: pertanyaan yang TIDAK mengubah apa pun — bebas dari aturan aggregate; boleh langsung SQL/tabel baca.

#Command Bus / Query Bus & Mediator

Mediator pattern (GoF) dalam wujud modern: pemanggil tidak tahu handler siapa; ia menyerahkan command/query ke bus, bus mencari handler-nya. Manfaatnya: middleware lintas-perintah (logging, validasi, transaksi) tinggal ditempel di bus.

#CQRS-lite vs CQRS Penuh

Tingkatan adopsi yang realistis:

Tingkat	Bentuk	Kapan Cukup
CQRS-lite	Satu DB, dua jalur kode: write via aggregate/repository, read via query object langsung	90% aplikasi — asimetri ringan
CQRS + read store	Read model denormalisasi tersinkron via event	Query berat/berbeda skala baca-tulis
CQRS penuh + event sourcing	State = replay events (ep.22)	Audit penuh, replay historis

Warning

CQRS penuh tanpa kebutuhan nyata = distributed monolith kecil: sinkronisasi read model, eventual consistency, debugging lebih sulit. Mulai dari lite.

#Real-World Implementasi

// Command + handler:
export class PlaceOrder { constructor(
  public readonly customerId: string,
  public readonly items: OrderItemDto[],
) {} }
 
@CommandHandler(PlaceOrder)
export class PlaceOrderHandler implements ICommandHandler<PlaceOrder> {
  constructor(private orders: OrdersRepository, private eventBus: EventBus2) {}
  async execute(cmd: PlaceOrder) {
    const order = Order.place(cmd.customerId, cmd.items);
    await this.orders.save(order);
    this.eventBus.publishAll(order.pullEvents());
    return { orderId: order.id };
  }
}
 
// Query handler - BEBAS aggregate, langsung proyeksi:
@QueryHandler(ListOrders)
export class ListOrdersHandler implements IQueryHandler<ListOrders> {
  constructor(private db: PrismaService) {}
  async execute(q: ListOrders) {
    return this.db.orderView.findMany({ where: { customerId: q.customerId } });
  }
}
 
// Controller: bus saja, nol logika:
@Post() create(@Body() dto) { return this.commandBus.execute(new PlaceOrder(...dto)); }
@Get() list(@Query() q) { return this.queryBus.execute(new ListOrders(q)); }

type Dispatcher struct {
    commands map[string]CommandHandler
    queries  map[string]QueryHandler
}
func (d *Dispatcher) Dispatch(cmd any) (any, error) { /* lookup by type */ }
 
type PlaceOrderHandler struct{ orders domain.OrderRepo }
func (h *PlaceOrderHandler) Handle(ctx context.Context, c any) (any, error) {
    cmd := c.(*PlaceOrder)
    order := domain.Place(cmd.CustomerID)
    return order.ID(), h.orders.Save(ctx, order)
}
 
type ListOrdersHandler struct{ views *ReadStore }
func (h *ListOrdersHandler) Handle(_ context.Context, q any) (any, error) {
    return h.views.OrdersByCustomer(q.(*ListOrders).CustomerID), nil
}
// Wiring sekali di main.go - graph eksplisit gaya Go.

final class PlaceOrderAction {          // command handler sebagai action
    public function __construct(private OrderRepository $orders) {}
    public function handle(PlaceOrderCommand $cmd): array {
        $order = OrderEntity::place($cmd->customerId);
        $this->orders->save($order);
        return ['order_id' => $order->id()];
    }
}
 
final class ListOrdersQuery {           // query object - langsung read view
    public function __construct(private Connection $db) {}
    public function rows(string $customerId): array {
        return $this->db->table('orders_read')
            ->where('customer_id', $customerId)->orderByDesc('placed_at')->get()
            ->all();
    }
}

#Proyeksi Read Model

Kunci CQRS+read-store: proyeksi — subscriber event OrderPlaced yang menulis baris siap-baca:

orders_read (denormalized)

CREATE TABLE orders_read (
  order_id TEXT PRIMARY KEY,
  customer_id TEXT NOT NULL,
  total_minor INT NOT NULL,
  items_count INT NOT NULL,
  placed_at TIMESTAMPTZ NOT NULL
); -- ditulis oleh projector saat OrderPlaced; query list tak pernah JOIN lagi

#Praktik

Target outline: split endpoint create-order (command) & list-orders (read model optimized).

1. Endpoint POST /orders -> jalur COMMAND:
   DTO -> command object -> handler -> aggregate Order (ep.19)
2. Endpoint GET /orders?customerId= -> jalur QUERY:
   query object -> tabel/view orders_read (bukan aggregate!)
3. Buat proyeksi: listener OrderPlaced menulis orders_read
4. Benchmark: seed 100k order; bandingkan GET list sebelum
   (JOIN via repo) vs sesudah (read table flat)
5. Tulis ADR mini: cukup CQRS-lite atau butuh read store?
   (data benchmark = argumen)

[x] Command TIDAK bisa dipanggil via GET; query TIDAK mengubah state
[x] Query handler bebas import aggregate/domain (grep bukti)
[x] Latency list-orders turun signifikan setelah read model
[x] Eventual consistency disadari & didokumentasikan:
     POST lalu GET instan BISA belum terlihat (delay proyeksi)

Tip

Untuk UX yang sensitif delay, pola umum: response POST mengembalikan orderId, UI redirect ke detail yang dibaca dari WRITE side (by-id konsisten), list baru pakai read model.

#Penutup

Rangkuman episode ini:

CQRS memisahkan model tulisan (aggregate+invarian) dari model baca (proyeksi siap-tampil).
Mediator/command bus memberi tempat middleware lintas-perintah; implementasinya native di NestJS, manual-di-Go, action/query-object di Laravel.
Adopsi bertingkat: mulai CQRS-lite satu DB; read store hanya saat data membuktikannya.

Episode 21 melangkah ke integrasi antar bagian sistem: Event-Driven Architecture — broker, idempotency, saga, dan order-created yang memicu email + statistik di ketiga stack. Sampai jumpa!