Do DDD and BPM Fit Together? The Strategic Perspective
Introduction: Is the Process Model Part of the Domain, or Infrastructure?
There is one discussion I keep having in projects, and it goes like this: Does the process model belong to the domain, or is it infrastructure? Is it part of the application, or not?
The question may sounds academic at first, but it has very practical consequences. I like to think of it in terms of a single application following a Clean Architecture approach: An application built this way consists of a domain core, use cases around it, and an outer ring of infrastructure: databases, messaging systems, frameworks. So where does the process model live? Is it part of the domain and the use cases it encodes; or is it just another infrastructure detail, like the choice of database?
My position: The process model is part of the domain. It describes how the business works: the flow, the decisions, the rules that define why a step exists. The engine that executes it, the deployment pipeline, the runtime stack, that is infrastructure. Confusing the two is the root cause of many BPM failures I see in customer projects.
In this first article of the series, I want to build the foundation for this argument: what DDD and BPM each bring to the table, how their modeling approaches complement each other, and how they tackle questions like model authority.
The Theoretical Foundation: What Each Concept Actually Is
Both DDD and BPM are often reduced to their technical artifacts. Let's be more precise.
Domain-Driven Design — Eric Evans' approach in his book Domain-Driven Design: Tackling Complexity in the Heart of Software — is built on two pillars:
- Strategic design: Identifying Bounded Contexts and their boundaries, and establishing a Ubiquitous Language shared between business and IT within each context.
- Tactical design: Patterns like Aggregates, Entities, and Domain Events that structure the domain logic in code.
Business Process Management — with BPMN 2.0 as its dominant notation it brings:
- A management concept: a continuous cycle: the KVP idea, the BPM lifecycle: modeling, executing, monitoring, and optimizing processes. The point is not the single diagram, but the continuous improvement of how the business works.
- A notation: with BPMN 2.0, the OMG provides a visual, executable standard for describing process flows: steps, decisions, events, and the order in which they happen. With precise semantics that process engines like Camunda can execute directly, making the model the running system rather than a description of it.
The figure shows how the DDD practices discussed map onto the BPM cycle: Event Storming and Domain Storytelling feed the discovery phase, Bounded Contexts structure the analysis, and Domain Events bookend the loop, from exploration to monitoring.
DDD practices in the BPM cycle: Domain Events open the loop in discovery, and can close it in controlling.
So where do the two concepts actually differ? BPMN talks about what happens and why: a gateway encodes a business decision, a lane assigns responsibility, a pool defines who interacts with whom. And DDD, in turn, talks about how and when: an Aggregate has a lifecycle, an Entity changes state over time, a Domain Event marks the moment something relevant happened.
The real difference is the perspective, not the territory: DDD looks at the domain as a structure: concepts, rules, boundaries, lifecycles. BPM looks at the same domain as a flow: sequences, decisions, responsibilities, and handovers between actors. Both describe the same business, so they inevitably overlap, and that is not a bug. It is exactly why they belong together: the flow tells you where in time a rule applies, and the structure tells you what the flow is actually operating on.
Two Modeling Worlds: Event Storming and BPMN
If DDD and BPM fit together, their modeling practices should fit together too. In practice, I usually see teams commit to one or the other: either the domain is explored and structured DDD-style, and the process landscape remains an afterthought. Or processes are modeled in BPMN, and the domain logic ends up buried in the tasks behind them. What I rarely see is both being used deliberately, each where it plays to its strengths.
Event Storming (introduced by Alberto Brandolini) is a workshop format for exploring a domain:
- It surfaces Domain Events: things that happened that matter to the business, and arranges them along a timeline.
- It exposes aggregates, commands, and policies almost as a by-product.
- It is deliberately cheap and iterative: sticky notes can be moved, discarded, and redrawn within minutes.
BPMN modeling is a format for specifying a process:
- It defines an executable flow with precise semantics: gateways, events, tasks, boundaries.
- It is deliberately rigorous, because it is the contract between business and the executing engine.
Where the friction comes from, and this is an argument I hear regularly against BPMN in the exploration phase, is twofold: the question of model authority, and the perceived complexity of the notation. By model authority I don't mean formal responsibility, I mean the knowledge it takes to change the model. Authority automatically lies with whoever has that knowledge. One can argue: someone who doesn't master the notation simply cannot adjust a BPMN diagram in a way that still executes. That makes the collaboration inherently unequal, and that, combined with the notation feeling too heavy for initial workshops, is why BPMN is often rejected for exploration.
Event Storming, on the other hand, is sometimes criticized for the opposite: you end up with a wall of sticky notes nobody can execute. But that criticism misses the point: the notation never claimed to be executable. Its sole purpose is the elicitation and a shared communication basis during the workshop, not a specification for an engine.
The two work best when used in sequence: Event Storming first, to understand the domain and its boundaries. BPMN second, to specify the processes that cross or orchestrate them. The Domain Events from the workshop become the anchors of your BPMN boundaries. And the aggregate boundaries tell you which parts of the flow deserve to be a black box: everything that happens inside an aggregate is internal domain behavior, it does not belong in the BPMN process as a sequence of steps. A process step like Reserve Charge becomes a single service task that delegates to the aggregate, instead of modeling validate charge → check inventory → reserve → record booking as four separate flow steps. That is exactly how you keep the executable model from bloating into technical plumbing.
Domain Storytelling: Clarifying the Details Before Modeling Them
Between rough exploration and precise specification, there is a gap: the details of how people actually work. This is where Domain Storytelling (from Stefan Hofer and Henning Schwentner) comes in for me: as an additional tool for the critical parts of a domain, especially those with lots of user or tool interactions, where a close look at how actors work through them pays off.
The idea is simple: A domain expert tells a concrete story from their daily work: "A customer calls in, the clerk looks up the order, checks the batch records, and issues a refund", while the facilitator records it in a pictographic language of actors, work items, and activities.
Why this matters for BPM:
- It clarifies who does what: the actors and their responsibilities often map directly to pools and lanes later.
- It surfaces domain vocabulary in context: you hear the expert say Charge, Order Item, or Vorgang and learn what they actually mean.
- It exposes variations and exceptions that a happy-path BPMN model would miss.
The outputs of a Domain Storytelling session are ideal input for detailed BPMN modeling: the story gives you the sequence, the actors, and the terms, and often the first hint at where one Bounded Context ends and the next begins.
The (Alleged) Problem of Model Authority in BPMN
This brings me back to the concern from the exploration discussion: model authority. If changing the model requires knowledge of the notation, and of the engine's execution semantics, then authority automatically sits with those who have that knowledge. The business cannot simply adjust an executable BPMN diagram and expect it to keep running. Doesn't that make BPMN an IT artifact by nature?
I don't think so, because the conclusion rests on the wrong expectations. Behind it usually stands the hypothesis that the business must be able to change the executable model autonomously, a low-code expectation. But working with BPMN means working with hypotheses about the process itself: the model encodes our current understanding of how the business works, and every change is a new hypothesis that needs validation. From that angle, the conclusion confuses two different kinds of models:
- A strategic process model, high-level, focused on the business flow, free of technical details. This is where the strategic part of BPM lives: aligning on how the business works. I had very good experiences using exactly this kind of BPMN model in first workshops. It keeps the notation-question small, communicates the flow, and it is already in the language that the executable model will use later.
- An executable process model: the refined version, enriched with technical details, delegated to those who implement the tasks and sub-processes behind it.
The key insight: the technical details that create the knowledge barrier don't belong in the business-relevant model in the first place. They belong in separate technical sub-processes and in the domain services behind the tasks. A model that keeps this separation clean stays readable, and changeable, for domain experts, because adjusting the flow or renaming a task doesn't require knowing how the engine executes it.
One clarification is important here: BPMN is not a low-code approach. I don't want the business to adjust processes completely on their own and push them to production without any quality assurance, an executable model deserves the same review discipline as code. What the business should be able to do is add or move model elements without knowing the engine's execution semantics, a new task here, a gateway moved there, a step renamed. That is contribution, not self-service. Authority over the model grows from collaboration between both sides, the business shapes the flow, the developers understand it and ensure it still executes.
My bottom line: BPMN dares, and in my opinion manages, the balancing act between being understandable for the business and being machine-readable and executable at the same time. That is precisely what makes it valuable: no second notation is needed to bridge the gap between the workshop wall and the running system. But the greatest value emerges when you combine the approaches: start with Event Storming and Domain Storytelling to build a shared understanding fast, and translate their results into BPMN deliberately, ideally into a strategic process model that evolves with every workshop. The practices are not competitors; they are stages of the same journey.
Conclusion: One Domain, Two Perspectives
So, do DDD and BPM fit together? I say yes, and the answer started with the question of where the process model belongs. It is part of the domain. It captures business decisions, business rules, and business vocabulary in executable form. The engine and everything around it is infrastructure, in the same ring of your application as the database.
From that position, the rest falls into place:
- DDD and BPM look at the same domain from two perspectives: structure and flow, and that overlap is a feature, not a bug.
- Event Storming explores the domain and its boundaries; the aggregate boundaries show where the executable model deserves black boxes instead of step-by-step plumbing.
- Domain Storytelling clarifies the concrete details of how the work happens: actors, vocabulary, and the exceptions a happy-path model would miss.
- The model authority concern is real, but it dissolves when the model is cut well and when you genuinely collaborate with the business on the model working on it together from the start, no threshold of "not being allowed to touch it" ever builds up in the first place. A strategic process model for the business, technical details delegated to sub-processes and services. Contribution, not self-service.
- And BPMN manages the balancing act that makes it all work: understandable for the business, machine-readable and executable at the same time.
Where does this lead? The next logical step is turning these boundaries into architecture, but that is a story for the next article.