In an earlier post, I introduced the idea of building blocks in EventModeling.

Today I want to go deeper. Because once you truly see these blocks, something interesting happens: most business processes stop looking complex.

In EventModeling (EM), I consistently see four core patterns, four ways change and information flow through a system.

Not frameworks, not layers, not technical abstractions. Just patterns of intent, decision, and outcome. And almost every business process can be decomposed into combinations of these four. There are exotic exceptions, but in practice, these four carry you remarkably far.

1) State change pattern

A human decides to change the business state

This is the most intuitive pattern. A user provides input. An action is taken. A command expresses intent. A business event records the outcome.

Shape:

Actor → Command → Business Event

L&H example

A back-office agent cancels a policy from inception.

• Actor: Back-office agent
• Command: CancelPolicyFromInception
• Payload: policyId = “policy-123”
• Event: PolicyFromInceptionCancelled
• Event data: policyId, cancellationDate

What matters here is not the UI or the API; what matters is that a business decision was made and durably recorded.

2) State view pattern

Understanding the present from the past

Nothing changes here. This pattern exists purely to understand the system. We reconstruct current state by replaying past events into a projection, and then query it.

Shape:

Past Events → Projection → Query → UI

L&H example

A back-office agent wants to see a list of lapsed policies. Here we have no command, no resulting event, and no mutation of state. Just a question answered from accumulated truth. This pattern is often underestimated, yet it’s what makes event-based systems usable by humans.

3) Automation pattern

The system acts without a human

Structurally, this looks like a state change, but the actor is not a person. It’s time, or a scheduler, or a background process. The intent still becomes a command. The outcome still becomes a business event.

Shape:

Projection (To-Do) → Automation → Command → Business Event

L&H example

Every night at midnight, a scheduled job runs. It checks for policies that are pending and should now go on risk. No human clicks anything. But business rules still apply. And state still changes. Automation is not “magic”, it’s just a non-human actor playing by the same rules.

4) Translation pattern

Turning foreign facts into internal truth

This is the most subtle, and one of the most important patterns. External systems speak their own language. Your system must not simply mirror it. Instead, external events are interpreted, validated, and translated into your business language.

Shape:

External Event → Process → Command → Internal Business Event

L&H example

Party data such as the one of policy owner, policy payer, or life insured, lives in an external CRM. That CRM emits an event:

• External event: PartyAddressUpdated
• Payload: partyId

Our system consumes it. A process checks:

• Is this party a policy owner?

• If yes, which policy?

• Is this party a policy owner?

• If yes, which policy?

If we found a match and the external event is relevant, we translate it:

Command: ChangePolicyOwnerAddress
Internal event: PolicyOwnerAddressChanged

• Command: ChangePolicyOwnerAddress
• Internal event: PolicyOwnerAddressChanged

This distinction matters. The first event is external fact. The second is internal business truth. EventModeling makes this boundary explicit — and safe.

Why this matters

Once you internalize these four patterns:

Modeling becomes faster
Discussions become clearer
Architectures become calmer
Processes become explainable

• Modeling becomes faster
• Discussions become clearer
• Architectures become calmer
• Processes become explainable

You will stop inventing custom flows. You will stop arguing about layers. Instead, you will start assembling systems from known, reliable building blocks. Most importantly: the model becomes the shared plan.

Everything else, UI, APIs, services, etc. follows naturally.

Originally published on LinkedIn (2026-02-02): https://www.linkedin.com/pulse/eventmodeling-building-blocks-four-patterns-explain-every-schenker-pjgue