Is DCP an event-sourcing framework?

No. DCP has no persistence model, no event store, and no replay semantics. It is an interchange vocabulary for describing project-coordination changes between systems, not a pattern for how one system stores or rebuilds its own internal state.

Can I use event sourcing and DCP together?

Yes. A system can be event-sourced internally, replaying its own append-only log to rebuild state, while also emitting DCP events externally whenever a coordination-relevant change occurs, such as a decision being recorded or a task being completed. The two operate at different layers and do not conflict.

Does DCP define a standard event schema like an event-sourcing framework would?

DCP defines a closed set of 8 entity types and validates every message against JSON Schema, but that vocabulary is for cross-system interchange, not for how an individual application models or stores its own domain events internally. Event sourcing leaves that internal schema entirely up to each application.

DCP vs. Event Sourcing

Event sourcing and DCP both put events ahead of snapshots, but they solve different problems at different scopes. Event sourcing, as described by Martin Fowler, is an application architecture pattern: capture every state change as an event and rebuild current state by replaying the log. DCP is an interchange vocabulary that lets independent agents and systems tell each other what changed. One is about a system remembering itself; the other is about systems talking to each other.

The money question

“We already use event sourcing internally — why would we also need DCP?”

Because event sourcing was never designed to leave the building. Fowler’s pattern prescribes an append-only log of domain events (OrderCanceled, ItemAdded) that one application replays to reconstruct its own state. Every system that adopts the pattern invents its own event types, its own schema, its own field names — there is no shared vocabulary across vendors, and the pattern doesn’t claim to offer one. That’s a deliberate, reasonable scoping choice: internal persistence design shouldn’t have to negotiate with the outside world.

DCP starts exactly where that scoping choice ends. It doesn’t care how — or whether — a system persists its own state internally. It defines a closed, cross-vendor vocabulary of 8 entity types (Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone) so that when a coordination-relevant change happens, any receiving agent — regardless of what database or replay strategy produced that change — can parse it the same way.

Event sourcing is how a system remembers its own state; DCP is how independent systems tell each other what changed.

Side-by-side

	DCP	Event Sourcing
What it is	An interchange protocol — a vocabulary for project-coordination messages exchanged between agents and systems	An internal architecture pattern for one application’s persistence layer
Scope	Cross-system — designed to travel between independent, vendor-neutral agents	Single-system — the event log belongs to one application’s domain model
Shared vocabulary	Yes — 8 closed entity types plus a controlled verb vocabulary, portable across implementations	No — each system defines its own event types (`OrderCanceled`, `ItemAdded`); nothing is standardized across systems
Persistence / replay	Not DCP’s concern — DCP says nothing about how a receiver stores or reconstructs state	The core mechanic — state is derived by replaying an append-only log; the log is the system of record
Validation	Every message validated against JSON Schema (2020-12), 14 schemas as of 2026-07-03	Application-defined — validation, if any, is whatever the implementing system builds for itself
Standardized?	Yes, in the sense of a shared, versioned, publicly documented vocabulary (SPEC, Apache-2.0/CC-BY-4.0)	No formal spec or governing body — a widely used pattern popularized by Martin Fowler, not a ratified standard
Relationship	Complementary — can be the thing a system emits externally after an internal state change	Complementary — can be the thing that produces the state change DCP later reports

Both share a philosophy worth naming: neither treats state as a static snapshot. Event sourcing rebuilds state from a sequence of changes rather than overwriting a row; DCP communicates a project’s changes rather than shipping a dump of current records, an emphasis the event reference echoes directly — a DCP Event must carry entity, delta, or refs, not a full-state copy. That shared instinct is where the resemblance ends. Event sourcing is a pattern for one codebase; it has no ratifying body, no cross-vendor field names, and no notion of what “the same event” would even mean to a second, unrelated system. DCP exists specifically to answer that second question.

Do they work together?

Yes, cleanly, and there’s no tension in doing so. A system can be fully event-sourced internally — replaying its own append-only log to rebuild Task or Order state exactly as Fowler describes — and separately emit a DCP event any time something coordination-relevant happens: a decision gets recorded, a review request is opened, a milestone is reached. The internal event log and the outbound DCP message don’t need to share a schema, because they’re solving different problems. One is a replay mechanism; the other, described further in why a coordination vocabulary, is a shared language for telling other agents what just happened.

Because DCP is transport-neutral, an event-sourced system can publish DCP events from the same place it appends to its own log — no separate infrastructure is required, just a translation step from internal domain event to one of the 8 closed entity types. For how this differs from comparisons against protocols that do define wire-level transport, see the comparison hub for the full set of DCP comparisons.

By InterIP Networks · Last updated 2026-07-01.