Strategic Design

A context map is a diagram showing all the bounded contexts in a system, how they connect, which one leads (upstream) vs follows (downstream), and which teams own each one.

An Anti-Corruption Layer is a translation wall between your code and someone else's system, so their messy or different data model doesn't leak into and pollute your own model.

A domain vision statement is a short written description of the core domain, its value, and why it will make the product win — a compass for what's most important to build well.

This is Event Storming - a workshop where people from business and tech stand at a wall and write domain events (things that happened) on orange sticky notes in time order, to quickly build a shared picture of how a system or business process really works.

Core subdomains are the special sauce that makes the business win — you build these yourself and invest your best people. Generic subdomains are things every company needs (like sending email or storing files) that don't set you apart — buy or reuse them instead of building custom.

Ubiquitous language is a shared vocabulary that developers and domain experts both use — the same words in code, docs, and conversation — so nothing gets lost or twisted when translating between how the business talks and how the software is built.

Look for places where the same word is used differently, where one team owns a process end-to-end, or where business rules and data change together but not with the rest. Those cracks show where boundaries naturally sit.

The context whose model the other side has to adapt to is 'upstream' (it leads); the one that changes to fit is 'downstream' (it follows). Getting this right tells you who needs to warn whom before making changes.

In Customer-Supplier, the downstream team has a real say - they can ask the upstream team to build things for them and get prioritized. In Conformist, downstream has no leverage and just accepts whatever upstream provides.

Open Host Service means building one well-documented shared API instead of custom integrations per consumer. Published Language means that API's data format follows a standard, well-documented schema everyone can read - without it, consumers still have to guess.

Highlighted Core means marking which parts of an existing model are the core domain — with a diagram, document, or comments — without moving any code, so everyone can see what matters most.

Besides orange notes for events, Event Storming boards use other colors for who did something (actors), what they tried to do (commands), automatic rules that react to events (policies), information someone needs to decide (read models), and outside systems involved (external systems).

Buy generic stuff (like email sending) because everyone needs it and vendors already solved it well. Build core stuff (your unique selling point) yourself because no vendor sells your competitive advantage. Supporting stuff is usually built in-house too, but kept simple, since it's specific to you but not what makes you special.

Ask 'is this exactly the same problem every company has, solved the same way?' If yes (like sending SMS), it's generic — buy it. If it's tailored to how this business runs (like a custom discount-eligibility calculator) but doesn't make customers choose you, it's supporting — build it, but don't over-invest.

Don't force one meaning of 'Order' everywhere. Let each service keep its own precise definition inside its own boundary, and put a clear translation step where the two services talk to each other, so nobody assumes a word means the same thing on both sides.

An Anti-Corruption Layer - a translation layer at the boundary that converts the legacy system's data and concepts into Billing's own clean model, so Billing's code never has to understand or depend on the legacy shape directly.

The map shows not just how systems connect but how the teams behind them cooperate or don't. Conway's Law says software tends to mirror the org chart, so tense or siloed team relationships usually show up as messy technical integrations, and vice versa.

On an Event Storming board, clusters of events that a business rule must keep consistent together hint at an aggregate boundary; places where vocabulary or ownership visibly changes, or where people keep disagreeing, hint at a bounded-context boundary.

Not always. Sometimes one subdomain needs several contexts to build, and sometimes one context handles parts of several subdomains. Assuming it's always a perfect one-to-one match makes teams draw the wrong boundaries and either overload one service or split something that should stay together.

The code's names don't match what the business actually says, which is a warning sign the design has drifted from the real domain. The reviewer should flag it and suggest renaming things to match the real terms, like Ledger.postPayment(), before the mismatch gets baked in further.

Don't just bolt on a field or flag for the new idea. Go talk to the domain experts about what 'Chargeback Hold' really means and why it matters, then change the code's actual shape — new class, new state, new rules — to represent it properly, and use that exact name everywhere afterward.

It means deliberately assigning your strongest domain modelers to the highest-value core, not spreading talent evenly; an abstract core is a further step where you pull the deepest shared concepts across several related subdomains into one small, careful model everyone else builds on.

The provider context publishes a stable, well-documented public API and/or event schema (a "published language") that many consumers can integrate against, instead of exposing its internal model directly to each one.

Teams pull people from every group that owns a piece of the system into a working session, list every real connection between systems by looking at actual code and traffic (not just docs), and agree on direction together. Someone then owns re-checking it periodically, or it goes stale.

Event Storming comes in a few 'zoom levels': Big Picture covers the whole business roughly with lots of people, Process Modeling zooms into one process with more detail, and Design Level zooms further into one part of the system with full technical precision.

DDD names relationship types between two teams' contexts - Customer-Supplier (supplier adapts to consumer), Conformist (consumer just accepts supplier's model), Partnership (co-design together) - chosen by relative priority, trust, and negotiating power.

Maps go wrong when nobody updates them (drift), when they're drawn without the people who really know the integrations (blind spots), or when they're treated as permanently true. This usually shows up quietly for a while, then causes a surprising break during a deploy or incident.

A Shared Kernel means two teams literally share some of the same code and model. Any change to it needs both teams' agreement, which is slow - it's only worth it when the shared part is small, stable, and genuinely needs to be identical everywhere.

A cohesive mechanism is a self-contained algorithm, like a rule engine or route solver, pulled out of the core model into its own component, so the core model can stay about business meaning while the mechanism handles the complex computation.