Event-Driven Architecture in Large Enterprises

The vision for Event Driven Architecture is genuinely compelling.

Build your systems around business events. When something meaningful happens in a domain — a payment is made, an account is opened, a limit is breached — the fact is published, post fact. Other domains consume it. They react. They choreograph. No tight coupling. No synchronous chains of calls. Just a clean, observable flow of business reality, expressed as events, propagating naturally across your enterprise.

Done well, event-driven architecture promises something most architecture functions aspire to achieve, but rarely realise. Systems that actually reflect how the business works, not the other way around.

The domain model drives the event model. The event model drives integration. Consuming domains build on a shared vocabulary of business outcomes. The architecture becomes a living representation of the enterprise — legible, evolvable, decoupled.

It’s a vision worth pursuing. The problem is what happens when you try to build it.

The first thing that breaks is the definition of a business event.

In theory, a business event represents something meaningful that happened in a domain. A fact. An outcome. Something the business would recognise and care about. In practice, defining what that actually means requires domain experts — people who can articulate business outcomes clearly, separately from the systems that support them.

Most organisations don’t have them.

Product teams and business stakeholders rarely think in event models. They think in features, in processes, in outcomes — but not in the crisp, bounded, unambiguous terms that event-driven design requires. When asked “what are your key business events?”, the honest answer in most organisations is a long silence, followed by someone pointing at a system.

So engineers fill the gap. They interpret. They proxy. And what gets encoded as business events are technical outcomes — system states, database transitions, API responses — renamed to sound like business vocabulary. A field update becomes an event. A status flag change becomes an event. The language creates a facade that sounds right. The model underneath doesn’t.

Then the legacy problem compounds everything.

Most large organisations aren’t building greenfield. They’re working around monolithic platforms — core banking systems, payment engines, legacy CRMs — that were never designed to emit business events. These systems hold the most critical business logic in the enterprise, but that logic isn’t encapsulated or expressed neatly. It’s scattered across batch jobs, stored procedures, downstream reconciliation processes, and institutional memory.

Getting a real business event out of these systems — something that says “a payment settled” as a coherent business fact — would require building a translation layer inside the domain boundary. Something that understands the raw data changes, knows the business rules, and synthesises them into a meaningful business event. That requires a specific skillset. It requires organisational investment. It requires the team managing the legacy platform to take on scope they rarely have appetite or skillset or funding for. Most importantly, they don’t have the vision for it.

So instead, organisations reach for Change Data Capture.

CDC is technically elegant. Stream the raw data changes directly from the database layer, expose them to consumers, and let the event bus carry them. It’s low effort, it’s real-time, and it sidesteps the hard problem entirely. What it produces is not business events. It’s a stream of table updates — atomic at the row or entity level, silent on what any of it means.

“Account record updated” is not “customer completed onboarding.” “Payment row modified” is not “payment settled.”

The data moved. The business outcome remains opaque.

And then the logic starts to bleed.

Consumers receive the raw stream. They need to make sense of it. So they build their own interpretation — stitching together multiple data updates and streams, encoding their own understanding of what the combination means, embedding that logic silently in their own systems.

A payment event arrives. The account domain consumer interprets it as a signal to recalculate available balance. The credit domain consumer interprets it as a trigger to check overlimit status. The collections domain has its own read entirely. None of these interpretations are wrong — but none of them are coordinated. Each domain is encoding its own version of what “payment complete” means, in its own codebase, invisible to every other team.

Over time, the business starts speaking system language. “Payment complete” becomes the shared vocabulary — not because anyone defined it that way, but because the system emits it and everyone has built on top of it. The architecture was supposed to reflect the business. Instead, the business has quietly conformed to the architecture.

The coupling hasn’t gone away. It’s just moved somewhere harder to see. The technology and technical integrations get delivered, but the real value of event driven architecture does not get realised.

Every organisation attempting event-driven architecture arrives at the same problems through a different path. The scale of the legacy estate, the maturity of the product and engineering teams, the organisational boundaries, the funding model — all of it shapes how the problems described above manifest and how deeply embedded they become before anyone names them clearly.

There is no universal prescription here. There are many tools, methodologies and frameworks available to model domains and define events. Often times, these become proxies for the foundations that need to be in place to realise the promise of event driven architectures.

What follows are not solutions. They are foundations — the pre-conditions that need to exist for the promise of event-driven architecture to have any real chance of being realised.

Foundation 1: A consistent enterprise definition of what a business event is

Before any domain starts designing events, before any Event Storming session is facilitated, the organisation needs to answer a more fundamental question: what do we actually mean by a business event?

Not in a specific domain. Across the enterprise. Consistently.

This means establishing a shared contract — not a technical schema, but a conceptual standard — that defines what a business event must convey. At minimum: the business outcome it represents, expressed at the right level of atomicity. The domain context it originates from. The business process entity being affected. Enough shared structure that any team, in any domain, producing or consuming events is working from the same underlying model.

Event Storming and other domain modelling techniques are valuable. But they produce events that are internally coherent within a domain and incompatible across domains unless this foundation exists first. Without it, every team defines events their own way. The inconsistency is invisible in the early stages and deeply embedded by the time it surfaces.

This doesn’t exist as standard practice in most organisations. It needs to be established deliberately, with both business and technical input, before the technical work begins.

Foundation 2: A translation layer as a deliberate investment within legacy domain boundaries

Change Data Capture is infrastructure. It is not an event model.

Treating CDC streams as business events is the path of least resistance, and it is also the source of most of the downstream problems described in this edition. Raw data changes are atomic at the row or entity level. Business outcomes are not. The gap between the two has to be bridged somewhere — and if it isn’t bridged inside the domain boundary that owns the legacy system, it gets bridged silently by every consuming domain independently.

The mitigation is a translation layer — a deliberate capability, inside the domain boundary, that understands the raw signals the legacy platform produces and synthesises them into meaningful business events. Something that knows that a combination of specific table updates, in a specific sequence, means “payment settled” — and says so explicitly, rather than leaving consumers to infer it.

This requires vision, skillset, and investment that most legacy platform teams don’t currently have. It also requires someone to make the case for it — which is an organisational and funding conversation as much as a technical one. But the alternative is permanently exporting the interpretation problem to consuming domains, which is precisely where business logic bleeds and where the hidden coupling accumulates.

Foundation 3: A domain event model as a first-class artefact

Every domain that participates in an event-driven architecture should be able to point at a document — accessible, readable, authoritative — that describes its event model. Not a technical schema registry. Not API documentation written for engineers. A business-readable description of what happens, to what, where, in the business process lifecycle of that domain.

This artefact should carry the same status as the data model. It should have joint ownership — business and technical — with both sides accountable for its accuracy and both sides capable of reading and verifying it. When a consuming domain wants to understand what a business event means, this is what they consult. When a producing domain changes an event, this is what gets updated first.

Right now, data models exist and are treated as authoritative. Event models, where they exist at all, live as technical schema documentation that business stakeholders can’t interpret and don’t own. That asymmetry is part of why the problems in this edition persist — nobody has drawn the boundary clearly enough for ownership to be real.

The domain event model makes that boundary visible. It is the artefact that turns “this domain owns its events” from a principle into something you can actually hold someone accountable to.

None of this is straightforward. The same organisational realities that make event-driven architecture necessary — complexity, scale, legacy, distributed ownership — are precisely the things that make these foundations difficult to establish. This is not a coincidence. It is the nature of the problem.

But the promise is real. Systems that reflect how the business works. A shared vocabulary of business outcomes. Architecture that is legible, evolvable, decoupled. That is worth the effort — provided the effort has the right foundations to start with.

The technology is rarely the constraint. The foundations almost always are.