Bounded Context in DDD: how to separate domains and integrations

Why split domains and introduce boundaries at all

Almost every enterprise system starts as “one monolith with modules.” At first that’s convenient: one repository, one database, shared reference data. But as functionality grows, modules start to fight over the same entities and rules. A change in one place unexpectedly breaks another.

The early symptoms are usually the same: several teams edit the same tables “just in case”; the common vocabulary drifts (the same “customer” or “order” means different things); everyone writes whatever they want to shared queues and topics, then has to cope with foreign formats; “shared” utilities pull half the system with them. Releases become infrequent because you have to test everything at once.

As the number of teams increases, the cost of coordination grows faster than development itself. Architecture becomes a negotiation club: to add one feature you must agree with multiple owners and review dozens of dependencies.

This is where a bounded context in DDD helps: explicit boundaries where the model and terms are aligned and only agreed interfaces go outside. The boundary isn’t “for show” — it makes changes local and predictable.

Key DDD concepts without extra theory

DDD is a way to agree on meanings. A team describes the system in the language used by the business and turns that language into a model: entities, rules, statuses, scenarios. When the model and language match, there are fewer requirement errors and less translation between analysts, developers and users.

A domain is a business area the system exists for (for example, procurement, accounting, support). Inside a domain there are usually subdomains: parts of different importance and complexity. Some areas are the “core” (what gives competitive advantage), others are routine and can be simplified.

A model is not a diagram or a database. It’s a set of concepts and rules: what counts as a “request”, when it’s “approved”, who can change an amount, which statuses are valid. The model matters in code and in the team’s speech.

A context is a place where words have precise meanings and a single model applies. The context boundary usually follows responsibility: who owns the rules, who owns the data, who decides on changes.

The same phrase can mean different things in different places. “Customer” for sales is a company; for accounting it’s a payer; for support it’s a user with incidents. Trying to have one definition for everyone makes the model brittle and changes painful.

DDD is especially useful in enterprise systems with many teams and integrations: modules evolve in parallel, requirements change often, there are lots of exceptions, terms are used inconsistently, and integration runs through multiple systems (ERP, CRM, service desk).

In systems integration projects these agreements about meaning are often more important than framework choice: they protect the system from chaos as it scales.

What is a bounded context and how to find its boundaries

A bounded context in DDD is a clear area of responsibility where words and rules mean the same for everyone involved. Inside that area the model doesn’t argue with itself: when you say “Order,” the team understands what it means here and which states it can have.

A good context is usually recognizable by three things: a clear purpose, clear owners and a stable language (terms don’t change meaning from screen to screen).

Key entities, business rules and the data those rules need should live inside the boundary, along with interfaces the context exposes to others (APIs, commands, scenarios). Keep integration agreements on the boundary: contracts, events, formats and compatibility rules. That way changes inside are less likely to break neighbors.

A simple width test:

• Too wide: many conflicting terms, frequent debates about “what’s right”, and very different goals in one place.
• Too narrow: every action requires calling 3–4 modules, and many unnecessary integrations for simple operations.

Example: in procurement “Supplier” is a counterparty with contracts and delivery terms; in accounting “Supplier” is a record for payments and reporting. Trying to make one “Supplier” for everyone turns the model into a compromise and quickly becomes obstructive.

To fix responsibility, appoint a context owner in advance: who approves terms, rules and model changes, and who resolves conflicts with neighboring teams.

How to identify domains: a practical approach for corporations

Start not from modules or organization charts, but from business goals. What decisions should the system help make daily: what can be approved, what cannot, where approvals are needed, where speed matters and where audit and accuracy matter.

Collect 5–10 key processes and roles, but don’t dive into screens and buttons. Describe work flows in plain words: who starts an action, who checks it, who is accountable, and what the correct result is.

Boundaries often appear where rules and vocabulary change. If the same words mean different things for different teams, that’s a signal you’re in different bounded contexts. For example, an “order” in procurement may be a purchase request, while in logistics it’s a concrete shipment with dates and statuses.

To avoid domain conflicts, mark sources of truth in advance. In enterprises one context often owns counterparties, another owns prices, a third owns stock levels. Don’t try to create one perfect shared object; agree who creates, who reads and what is the authoritative source.

A simple classification helps:

• Core: what gives the company its differentiation and where rules change most often.
• Supporting: important but not unique; these can be simpler.
• Generic: typical functions like authentication, notifications, reporting exports.

Example: for an integration project the core might be contract and purchasing limit management (lots of regulation and approvals), supporting might be shipment tracking and warranty records, generic might be user catalogs and roles. This helps decide where to build a strong domain model and where to avoid overengineering.

Step-by-step: how to create a context map and agreements

A context map makes it clear where one model ends and another begins. Start from language and responsibility, not tools or “perfect diagrams.”

Collect terms from real sources: screens, reports, emails, contracts, tickets. Note where a word is used and what people mean by it. The same “customer” in sales and support is often two different concepts, and it’s better to see that early.

Next, assign a data owner for each key term. The owner does not just “hold a table”; they are responsible for meaning, change rules and quality. For example, “Order Status” should have one owner even if five modules read it.

Sketch contexts on one page: 5–8 rectangles, each with a short purpose (one phrase) and boundaries. The goal is not a perfect split but the ability to say at any moment: “this is not ours” and “here is where ours begins.”

Then describe each context’s inputs and outputs: commands, requests, events, files. To keep agreements tight, record a minimum:

• a glossary of terms and their meanings per context;
• data owners and change rules;
• interfaces (what is provided and what is expected);
• integration method (API, events, exports);
• contract versions and compatibility rules.

The final step is to align boundaries with teams and release plans. Verify who maintains the contract, how to roll out changes without stopping neighbors and what to do in case of value conflicts (for example, via mapping or a protective layer around the model).

Integration rules between modules: what to decide in advance

Integrations break scaling more often from unclear expectations than from technology: who must do what, when, in what format and how to handle failures. Boundaries help, but without exchange rules data and responsibility start to “leak” between teams.

Synchronous API integration fits when you need an immediate answer: check a limit, get a status, calculate a price with current rules. Agree in advance which operations are critical, acceptable timeouts and what counts as a “normal” error (e.g., no data vs service unavailable).

An event-driven model is better when changes must propagate without tight dependencies: “Request approved,” “Invoice paid,” “Item received in warehouse.” This reduces coupling but requires discipline: events must be clear, stable and not a dump of the internal model.

Batch exchanges suit cases where online requests don't make sense: nightly reconciliation, reference data loads, exports to external systems. The downside is slightly stale data and late error detection.

Use simple criteria to choose sync vs async: if the user needs an immediate response — API; if it can be processed later — events; if delays of hours are acceptable — batch; if an external failure mustn’t block you — prefer asynchronous; if a single source of truth matters more than speed — prefer synchronous.

Contracts deserve special attention. Some things are painful to change later: versioning (how long old versions live), backward compatibility, error rules (codes, retry behavior, deduplication), data schema (required fields, date and amount formats), and responsibility for notifying and testing changes.

Example: Procurement emits an event “OrderConfirmed” and Accounting doesn’t fetch all details via a direct call but stores only what’s needed for ledger entries. Then changes in Procurement less often break Accounting even as teams grow.

How not to mix models: contracts, mapping and the anti-corruption layer

When two bounded contexts exchange entities directly, the model quickly becomes “infected” by foreign rules. Releases start breaking neighbors and teams argue about field meanings. The simple rule is: integration usually requires translation, even if data looks similar.

Translation is needed because the same word often means different things. In sales a “customer” may be a person; in billing a “customer” is a payer with a contract and limits. Pulling one object into another silently brings its constraints.

Anti-corruption layer (ACL)

Place the anti-corruption layer on the consumer side — the context that receives data. It accepts external messages, validates them, translates into local terms and only then persists.

In an ACL you typically map fields and formats (codes, dates, currencies), check semantics (for example, don’t accept a “closed” request as “ready for payment” if rules differ), isolate reference data (use local statuses and types, not remote ones) and handle mismatches (unknown values, missing fields, conflicting rules).

Data contracts: smaller and clearer

Keep contracts minimal and explicit: only what the consumer truly needs, plus clear values. Don’t “send the whole request”; send the fact and key attributes. Agree which fields are stable, which may be empty and what the authoritative source is.

A good practice is not to import foreign statuses and reference data. Treat external status as a signal and map it locally. For example, external APPROVED might become “Allowed to order” or sometimes “Requires review” if limits or roles don’t match.

If terms diverge, resolve it in the contract and mapping, not by creating a single universal reference. This keeps boundaries clean and prevents endless rework.

Events, processes and data consistency between contexts

Events between bounded contexts help teams avoid touching each other’s tables and depending on internal logic. But not every change should become an event.

Publish only what matters to other contexts and is understandable to the business: “Order confirmed,” “Invoice issued,” “Equipment shipped.” Internal or UI details like “User clicked a button” or “Status changed from 3 to 4” are better kept private: they change often and break integrations.

When a business process spans contexts, ask who manages it. If steps are independent, reacting to events is usually enough. If you need strict order, timeouts, rollbacks or manual decisions, a saga is often necessary. A saga is a process conductor: it checks step 1 finished, then triggers step 2, and compensates on failure (for example, cancels a reservation).

Idempotency is required because events can arrive twice: due to redelivery, retries or network failures. The consumer must safely handle duplicates. Practically, this means an event has a stable identifier and the handler records processing facts to avoid duplicates (don’t create a second invoice or debit money twice).

Agree on eventual consistency with the business and QA up front. After an event, data in another context may update in seconds or minutes. That’s acceptable if rules exist: where to show “in progress”, which actions are forbidden until confirmation and what delays are tolerable.

To keep events from becoming rumors, document each public event as a contract: name and business meaning, when it is published and who is the source, fields and their semantics (required and optional), delivery and ordering expectations (at least in words: duplicates and delays are possible), and versioning rules (how to add a field without breaking consumers).

Common mistakes that make scaling break development

Problems usually start not at the boundary-drawing stage but when teams grow and each module begins to change data and meanings independently. Even with bounded contexts agreed, poor ownership and integration practices turn changes into chains of bugs.

Mistake 1: drawing boundaries by tables instead of responsibility

A common scenario: a module is called separate because it has its own schema. But responsibility is blurred: who decides what “status” or “customer” means? Domain logic then spreads across services and triggers.

Mistake 2: one model for everyone because it’s faster

A single canonical entity seems convenient: less mapping, less code. But later every term starts to mean different things to different teams. “Order” in procurement and “order” in accounting follow different rules, and the single model becomes a compromise that hurts everyone.

Other typical breakdowns:

• shared reference data without an owner (edits happen “on request” without compatibility rules);
• cross-context transactions (any delay blocks everyone);
• integration via direct DB access or internal methods (dependency on implementation details);
• lack of contract versioning (one field breaks consumers);
• mixing “data” and “meaning” (copying foreign fields without understanding their interpretation).

Mini-example: procurement adds a new status “Partially Delivered,” while accounting uses the status as a trigger for ledger entries. If the contract isn’t versioned and there’s no explicit mapping or ACL, accounting will make wrong entries or miss them entirely.

A sign of maturity: each reference and event has an owner, contracts change by agreed rules, and integrations happen through public boundaries rather than “give direct access, it’s faster.”

Short checklist before splitting and growing teams

Before assigning modules to different teams, run a quick check. This ensures boundaries are not drawn by eye and integrations won’t become chaotic after a few releases.

Start with the main thing: every bounded context must have a clear goal and an owner. If you cannot explain in one sentence what the context is responsible for (and who decides on its model), the boundary is not ready.

Check the basics:

• data boundaries: what is stored here and what is read-only from outside;
• list of integrations and their type (API, events, batch);
• contract versioning and compatibility rules;
• reference data policy: single source of truth or copies, and who ensures quality;
• for cross-cutting processes — who orchestrates steps (a process in one context or a separate process module).

Then quickly assess model-mixing risks. If module A writes directly to module B’s tables or peeks into its internal fields, separation will be painful. Agree in advance: only through explicit contracts and clear mapping.

A readiness criterion is simple: the context can be released and changed independently. For example, the accounting team updates posting rules without urgent patches from procurement because of an internal field change. If that’s not possible, revisit boundaries and integrations before scaling.

Example: how to split procurement and accounting without pain

Imagine a corporation with procurement, warehouse, finance and ITSM. The team wants faster changes but currently everything lives in one database and any new report breaks half the system. Bounded contexts help distribute responsibility so growth doesn’t become endless coordination.

A typical starting split looks like:

• Orders: requests, approvals, supplier selection, lifecycle status.
• Deliveries: shipment, receipt, discrepancies, batches, documentation.
• Budgets: limits, cost lines, reservations, facts, control.
• Assets: inventory units, asset tags, movements, write-offs.

Pain begins where the same words have different meanings. “Order status” in Procurement is about approval and supplier selection; in Deliveries it’s about logistics and receiving. “Inventory unit” in Assets is an asset record; in Warehouse it’s a piece, a box or a batch. “Receipt” for Deliveries is quantity and quality confirmation; for Finance it’s the basis for recognizing a liability and processing payment.

Integrations should be split into events and requests in advance. For example, Deliveries publish event “ItemReceived” (order number, line items, quantity, dates) and Budgets and Finance subscribe and update their state. Procurement does not request Budgets for every UI action; instead there’s a small API: “check limit” and “reserve amount” with a clear contract.

To avoid returning to a monolith, enforce: no shared tables and no direct SQL between modules. Each context owns its database and model; exchange across boundaries goes via contracts (events and APIs) with explicit field mapping and meaning translation.

Next steps: pilot, infrastructure and change support

Start with a pilot, not an attempt to split everything at once. Usually 1–2 contexts where pain is already felt are enough: frequent team conflicts, complex releases, many manual approvals. Good candidates are contexts with clear business value and few external dependencies.

To keep the pilot focused, agree in advance how you will measure improvement. Three or four metrics and a retro every 2–4 weeks are enough: lead time for changes in pilot modules, number of requirement conflicts and task hand-offs, incidents after releases and recovery time, number of emergency fixes done “outside the rules” (manual syncs, direct DB queries).

Prepare a minimal set of infrastructure and rules so boundaries don’t drift: a common way to describe contracts, separate environments, monitoring. Initially it’s enough to have API/event docs with owners, test environments for integration compatibility, logs/metrics/alerts for key flows, backups and a recovery plan for critical data.

When the pilot shows results, you often hit infrastructure and service needs: servers for services and queues, storage, workspaces for teams, 24/7 support. A systems integrator can help deliver the full chain. For example, GSE.kz (gse.kz) as a supplier and integrator in Kazakhstan provides servers and workstations and handles deployment and support.

The main rule: expand the context map only after pilot boundaries survive several releases and incidents without reverting to a “single model for all.”