Choosing an approach: Aggregate, DCB, or Hybrid

The online shop is implemented three times — once with each plugin style. Before following the walkthrough, it helps to know which style you would reach for, and why this tutorial uses the Hybrid one.

The three styles in one table

	Aggregate-based	DCB-based	Hybrid
Event storage	One event log per aggregate instance	One shared, tag-filtered log per plugin	Both — per-aggregate logs and a shared DCB log
Consistency boundary	Per aggregate instance	Per command (optimistic)	Per entity type
Cross-entity decisions	Not directly supported	Supported (slices read across entities)	Supported for the DCB entities
Best when	Entity lifecycles are independent	You need consistency across entities in one command	Some entities are independent, others are interdependent

How to decide, per entity

For each entity in your plugin, ask:

1. Does its decision need to see other entities' events? → DCB.
2. Does a read model need to combine its events with another entity's events? → both entities should share a DCB log.
3. Is its lifecycle fully independent? → Aggregate.

If every entity points the same way, use that pure style. If the answers are mixed — which is common — use Hybrid, modelling each entity with the approach that fits it. The full reasoning lives in the App Guide's DCB concepts.

Why this tutorial uses Hybrid

The shop has both kinds of entity:

• Independent — Category and Customer are simple Add/Update/Archive lifecycles with no cross-entity needs → aggregates.
• Interdependent — Product+ProductDemand and Order+CatalogProduct benefit from shared, tag-filtered reads and cross-entity validation → DCB.

Hybrid is the most representative of a real application, so it is the spine of this tutorial. The two pure styles are kept as alternates for comparison.

Alternate implementations

• Aggregate-based — every entity as an aggregate.
• DCB-based — every entity in one shared DCB log.

---

Next: walk through the recommended implementation in the Hybrid walkthrough →