事件驱动CQRS架构下业务逻辑与内部流程的数据查询策略咨询

Hey there! I totally get where you're coming from—CQRS sounds straightforward on paper, but the nitty-gritty of real-world implementation can throw you for a loop. Let's tackle your core questions one by one:

1. Do I need to convert Read Objects to Command Objects when modifying resources via cron jobs? #

Short answer: Yes, but focus on identifiers rather than copying the entire object. Here's why:

• Your Read DB is optimized for view queries, so its schema or data structure might not match the domain model in your Command side (it could have denormalized fields, computed values, or lack critical business logic context).
• The Command DB is your single source of truth for business state. If you use a Read Object directly to make changes, you risk working with stale or incomplete data (since Read projections can have replication lag, or exclude fields needed to enforce business rules).

Practical approach: #

1. Query your Read DB to get the unique identifiers (e.g., IDs) of class x instances that meet your criteria (like last_changed_date > 5 days ago).
2. For each ID, fetch the corresponding domain model (Command Object) from your Command DB.
3. Execute your business logic on the Command Object (e.g., update its state based on your pre-defined conditions).
4. Persist the updated Command Object to the Command DB, then generate the corresponding event to sync the Read side.

This way, you leverage the Read DB's query efficiency while ensuring all state changes are rooted in the authoritative Command-side model.

2. Is querying the Command DB directly for eligible instances compliant with CQRS? #

CQRS is a pattern, not a strict rulebook—so it depends on your use case. Here's the breakdown:

• The core idea of CQRS is separating read and write responsibilities to optimize each for their respective workloads. Command DBs are typically optimized for writes (e.g., normalized schemas, transactional integrity), not complex ad-hoc queries.
• If your query is simple (e.g., fetching by ID, or a small range with proper indexing) and your Command DB can handle the load without impacting write performance, this is totally acceptable.
• However, for complex queries (like filtering by last_changed_date across millions of records), the Command DB might struggle with performance or lack the right indexes. In that case, using the Read DB to get IDs first (as outlined in question 1) is a better approach.

Key takeaway: #

Don't force yourself to avoid the Command DB for reads—just prioritize using the Read DB for query-heavy workloads where it adds clear value. CQRS is about solving problems, not adhering to dogma.

3. How to efficiently query millions of events for latest state when switching to Event Sourcing? #

Event Sourcing introduces new query challenges, but there are proven strategies to handle this at scale:

a. Use Snapshots #

• Generate periodic snapshots of your aggregate's current state (e.g., daily, or after every N events). When you need an aggregate's latest state, load the most recent snapshot first, then apply any events that occurred after the snapshot. This avoids replaying every single event from scratch.
• For your cron job example, you could maintain snapshots that include the last_changed_date field, making it easy to filter aggregates that meet your criteria without full event replay.

b. Build Purpose-Built Projections #

• Create a dedicated projection that consumes events in real-time and maintains a dataset optimized for your specific query (e.g., a table that tracks all class x aggregates with last_changed_date > 5 days ago). When your cron job runs, it can query this projection directly instead of scanning the entire event store.
• This is similar to how you use your current Read DB, but the projection is built directly from events rather than Command DB updates.

c. Optimize Event Store Queries #

• Choose an event store that supports efficient querying (e.g., filtering by aggregate type, event timestamp, or custom metadata). Add indexes to fields you frequently filter on (like last_changed_date stored as event metadata).
• Many event stores allow you to query events for a subset of aggregates (e.g., by date range) which can reduce the number of events you need to process.

d. Shard Aggregates #

• Split your aggregates into shards (e.g., by hash of the aggregate ID). When querying, you can parallelize the work across shards to speed up processing of large datasets.

Bonus: Prepare now for the switch #

Even if you're not using Event Sourcing yet, design your events to be immutable and capture all state changes—this will make it much easier to transition later. Also, keep your domain models focused on business logic rather than database-specific concerns.

内容的提问来源于stack exchange，提问作者Twisterr1000