Events vs Commands vs Queries: Domain Modeling in Event-Driven Systems

The most prevalent architectural anti-patterns in distributed systems stem from linguistic and conceptual ambiguity. When software engineering teams do not rigorously differentiate between an Event, a Command, and a Query, message schemas become muddled, microservices develop hidden temporal coupling, and boundaries between bounded contexts collapse.

To design robust event-driven architectures, you must master the fundamental semantics of domain messaging and understand the three foundational event transmission patterns: Event Notification, Event-Carried State Transfer (ECST), and Event Sourcing.

---

1. The Core Taxonomy: Events, Commands, and Queries

Every message traveling across a network socket belongs to one of three distinct categories:

A. Commands (Intents to Mutate State)

A Command is a request directed to a specific service or aggregate asking it to perform an action that will mutate state.

• Grammar: Imperative verb (e.g., SubmitOrder, DebitAccount, CancelSubscription).
• Targeting: Point-to-point. A command has exactly one designated recipient (handler).
• Mutability & Validation: A command can be rejected. The receiving aggregate validates business invariants (e.g., "Account has insufficient funds") and may throw a domain exception or return a validation error.
• Expected Outcome: Either a state transition occurs (yielding one or more Domain Events), or the command is rejected with an error.

B. Domain Events (Immutable Records of Past Facts)

A Domain Event is a statement of fact that something noteworthy has already occurred within a bounded context.

• Grammar: Past-tense verb (e.g., OrderSubmitted, AccountDebited, SubscriptionCanceled).
• Targeting: Publish-Subscribe (1-to-Many). The publisher emits the event into an event stream with zero knowledge of who (if anyone) will consume it.
• Immutability: An event cannot be rejected, canceled, or undone. It is an immutable historical reality. If an action was taken in error, a subsequent compensating event must be emitted (e.g., AccountDebitReversed).

C. Queries (Read-Only Information Requests)

A Query is a request for information that produces zero side effects on the system's state.

• Grammar: Interrogative phrase (e.g., GetAccountBalance, ListActiveOrders).
• Targeting: Directed to a read model, projection, or cache.
• Guarantees: Idempotent and safe. Repeated queries return the current state without altering domain state.

---

2. Comparison Matrix: Commands vs Events vs Queries

---

3. The Three Patterns of Event-Driven Interaction

Not all events are structured the same way. In Martin Fowler's classic enterprise architecture taxonomy, event-driven systems utilize three primary transmission patterns:

---

Pattern 1: Event Notification (Thin Events)

In Event Notification, the producer publishes a lightweight, "thin" message stating only that an event occurred, containing minimal identifying attributes (typically just entity IDs and timestamps).

Example Thin Event Schema:

Trade-Off Analysis:

• Advantage: Minimal payload size ($<200\text{ bytes}$). No risk of stale data embedded in events. High producer throughput.
• Severe Disadvantage (The Callback Storm): When $10$ downstream microservices consume USER_EMAIL_UPDATED, all $10$ services immediately invoke GET /api/users/usr_99812 over HTTP back to the Identity Service to fetch the new email address. This creates covert temporal coupling and can trigger a self-inflicted Distributed Denial of Service (DDoS) on the producer.

---

Pattern 2: Event-Carried State Transfer (ECST / Fat Events)

In Event-Carried State Transfer (ECST), the producer publishes a self-contained, "fat" message carrying the complete snapshot or modified delta of the domain entity.

Example ECST Event Schema:

Trade-Off Analysis:

• Advantage (Complete Autonomy & Resiliency): Downstream consumers (Warehouse, Billing, Analytics, Recommendation Engines) maintain their own local read-optimized databases (Projections) populated from the event stream. They never call back to the Order Service via HTTP. If the Order Service is down, downstream consumers continue operating with $100\%$ availability.
• Disadvantage: Larger network bandwidth footprint; requires rigorous schema versioning governance so producers do not inadvertently break downstream parsers when evolving entity fields.

---

Pattern 3: Event Sourcing (The Log as the Single Source of Truth)

In traditional CRUD architectures, the database stores only the current state (e.g., UPDATE accounts SET balance = 70 WHERE id = 1), permanently discarding historical intermediate states.

In Event Sourcing, state is never directly overwritten. Instead, the application appends an immutable sequence of business events to an Event Store. The current state of an entity is derived at any moment by replaying all historical events from $t=0$:

$\text{CurrentState}=\text{Fold}(\text{InitialState},[e_1,e_2,e_3,\dots ,e_n])$

---

4. Anti-Pattern Deep-Dive: "Commands Disguised as Events"

The single most dangerous anti-pattern in event modeling is naming an event as an imperative command or tailoring an event to the internal implementation requirements of a specific downstream consumer.

The Anti-Pattern:

An engineer in the Checkout team wants the Notification Service to send an email, so they write:

Why This Destroys Architecture:

1. Inverts Dependency Boundaries: The Checkout Service is now dictating how another domain (Communication/Notification) should behave, including specifying template names and UI rendering concerns.
2. Breaks Fan-Out Scalability: When the Analytics team or Fraud team also needs to know an order occurred, SEND_USER_EMAIL makes no semantic sense to them. The producer is forced to publish multiple bespoke "events" for each individual downstream team (SEND_USER_EMAIL, TRACK_ANALYTICS_EVENT, SCAN_FRAUD).

The Clean Architecture Fix:

Publish a pure Domain Event describing what happened in the producer's ubiquitous domain language, with zero directives:

The Notification Service independently subscribes to ORDER_COMPLETED, inspects its own configuration rules, decides whether an email should be sent, selects its own email template, and executes autonomously.

---

5. Code Deep-Dive: Domain Event Modeling & State Machine in TypeScript

Here is an enterprise-grade TypeScript implementation demonstrating a strict Domain Event lifecycle with metadata headers, type-safe discriminators, and immutable aggregate state folding:

---

Summary and Key Takeaways

1. Commands are intents targeted at a single handler that can be rejected upon business rule validation (PlaceOrder).
2. Events are immutable facts broadcast to multiple subscribers that represent historical reality and can never be rejected (OrderPlaced).
3. Event Notification (thin events) minimizes message byte size but causes high-concurrency callback storms on the producer.
4. Event-Carried State Transfer (ECST / fat events) delivers complete autonomy and resilience to downstream consumers by replicating state asynchronously.
5. Event Sourcing uses the append-only event log as the primary source of truth, reconstructing entity state through pure functional event folding.
6. In the next lesson, we will confront the most notorious distributed consistency trap in microservices: The Dual-Write Problem, and prove why naive database-then-Kafka commits always result in silent data corruption.