CQRS на собеседовании системного аналитика

Что такое CQRS

Command Query Responsibility Segregation. Greg Young 2010.

Разделить write model и read model. Они могут быть optimized differently.

Command vs Query

Command. Modifies state. Не returns data.

PlaceOrder(items, customer_id) → void / ack

Query. Returns data. Не modifies state.

GetOrder(order_id) → OrderDTO

Strict separation — каждый method either command или query.

Separate models

Write model:

• Optimized для consistency, validation.
• Normalized.
• Domain entities (rich models with business logic).

Read model:

• Optimized для queries.
• Denormalized (no joins).
• Multiple views per use case (admin view, customer view, analytics view).

Write side: Postgres normalized — orders, items, payments.
Read side: 
  - "OrderSummary" — denormalized, cached.
  - "CustomerHistory" — aggregated.
  - "RevenueDashboard" — pre-aggregated daily.

Synchronization

Write → events → projections → read models.

Order saved → "OrderPlaced" event published.
Subscribers update read models:
  - OrderSummary view.
  - CustomerHistory view.
  - Analytics aggregate.

Eventual consistency. Read models lag write — milliseconds-seconds.

Когда применять

Подходит:

• Read >> write workload.
• Multiple read views needed.
• Complex domain (combine с DDD + event sourcing).
• Performance read critical.

Overkill:

• Simple CRUD.
• Не есть scale issues.
• Маленькая команда без CQRS опыта.

CQRS добавляет complexity. Use selectively.

Связанные темы

• DDD для SA
• Event-driven архитектура для SA
• Архитектурные паттерны для SA
• Domain events для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на работах Greg Young, Martin Fowler.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.