AgentStack
SKILL verified MIT Self-run

Cqrs

skill-g1joshi-agent-skills-cqrs · by G1Joshi

CQRS command query responsibility segregation. Use for complex domains.

No reviews yet
0 installs
18 views
0.0% view→install

Install

$ agentstack add skill-g1joshi-agent-skills-cqrs

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Cqrs? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

CQRS (Command Query Responsibility Segregation)

CQRS is a pattern that separates read and update operations for a data store. Instead of using a single model for both, you have a Command Model (Write) and a Query Model (Read).

When to Use

  • High Disparity: Read load is 1000x higher than Write load (or vice versa).
  • Complex UI: The UI needs data shaped differently than the way it's stored (e.g., Dashboard aggregation).
  • Event Sourcing: CQRS is almost mandatory for Event Sourcing.

Quick Start (Conceptual)

// Command Side (Write) - Optimized for Integrity
class CreateOrderCommand { ... }
class OrderAggregate {
    create(cmd: CreateOrderCommand) {
        // Validate business rules
        // Save to DB (Normalized / Event Store)
    }
}

// Query Side (Read) - Optimized for Speed
class GetOrderSummaryQuery { ... }
class OrderSummaryProjector {
    // Listens to "OrderCreated" event
    on(event) {
        // Update a flat "Read DB" (e.g., ElasticSearch, Redis, Document DB)
        // optimized for the specific UI view
    }
}

Core Concepts

Separation

  • Commands: Intent to change state. Void return type (or Ack). Strict validation.
  • Queries: Request for data. No side effects. Returns DTOs.

Synchronization

The Read DB is eventually consistent with the Write DB. Logic (Projectors) syncs them via Events.

Best Practices

Do:

  • Start with Logical CQRS (Separate classes, same DB) before Physical CQRS (Separate DBs).
  • accept Eventual Consistency in the UI (Optimistic UI updates).

Don't:

  • Don't use CQRS for simple CRUD (It adds massive complexity).
  • Don't try to make the Read side fully real-time synchronized (You'll lose the scaling usage).

Troubleshooting

| Error | Cause | Solution | | :----------- | :---------------------------------------------- | :-------------------------------------------------------------------- | | Stale Data | Lag between Command execution and Query update. | UI design updates (spinners/optimistic updates); Check projector lag. | | Complexity | Over-engineering. | Revert to simple CRUD if the domain doesn't warrant separation. |

References

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.