Event-Driven Architecture

Domain events are the cleanest decoupling primitive in a Rails app. Order#after_create_commit :publish_order_placed lets billing, notifications, and analytics react without knowing about each other. This skill covers what to emit, how, and where event-driven goes wrong (event sourcing for everything is usually wrong).

The opinion

Emit domain events for cross-cutting concerns (notifications, audit, analytics). Use the transactional outbox so events publish atomically with the business write. Distinguish domain events (what happened in your bounded context) from integration events (what you tell other services). Use rails_event_store for in-app event handling. Do NOT adopt event sourcing as the default — it's a powerful but expensive pattern.

Domain events vs integration events

Don't mix them. Internal domain events are private — change at will. Integration events are public APIs and follow the same compatibility rules as your HTTP API.