Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 2 of 7 Beginner 25 min

The Shared Language Toolkit — DDD Core Vocabulary for Business Owners

Prerequisites: When Everyone Means Something Different — Why Disambiguation Matters

What You'll Learn

  • Define domain, bounded context, and ubiquitous language in plain terms and explain what each one prevents.
  • Classify a business area as a core, supporting, or generic subdomain and explain why the distinction matters for investment decisions.
  • Identify at least one bounded context in your own work and name the ubiquitous language it uses.
  • Describe what a domain event is and why it is written in the past tense.
  • Explain why a single unified vocabulary for the whole company is the wrong goal.

Why This Matters

This framework resolves the ambiguity of what words mean by establishing a ubiquitous language that is visible in every conversation and in code.

In Module 01 we saw what happens when business and engineering talk past each other — the Meridian Insurance product launch stalled for three months because the word "approval" meant four different things to four different teams. DDD core vocabulary is the direct answer to that problem. It gives you and your engineering team a shared toolkit of concepts — not just words, but precisely defined words tied to exactly who owns them and where they apply.

You do not need to be technical to use this vocabulary. In fact, the whole point is that it belongs to business owners just as much as to engineers. If you do not help shape the language your software is built on, you will end up with software that does not reflect how you actually work — and that costs real money to fix.

Core Concept

Domain: the territory, not the map

The word domain (the specific area of business a system is built to support; what the business does and cares about) sounds abstract, but it is just a precise word for something you already know: your business area. At Meridian Insurance, the domain is insurance — specifically, providing small business property coverage. It is not a software concept. It is the actual business territory that the software is trying to reflect.

Think of it this way: if you were explaining your job to a new hire who had never worked in insurance, everything you would have to explain is your domain. The risks, the rules, the relationships, the vocabulary — all of it.

Bounded context: where one language applies consistently

Here is where DDD gets genuinely useful. Complex businesses do not have a single unified vocabulary — and they should not. The word "customer" means something different to Sales, Billing, and Support. The word "approval" means something completely different to Underwriting and Claims. Trying to force one definition on everyone creates confusion and friction.

A bounded context (a clearly defined boundary within which a specific team uses consistent terminology and owns a coherent set of capabilities; the seams between bounded contexts are where translation happens) is a deliberately drawn boundary that says: inside this area, these words have these specific meanings, and everyone in this area agrees. Outside this area, the words might mean something different — and that is fine.

At Meridian, the Policy Context (owned by Underwriting) is one bounded context. Inside it, "approval" means a risk assessment decision: does this applicant qualify for coverage, and at what price? The Claims Context is a separate bounded context. Inside it, "approval" means a settlement authorisation: has this claim been validated and is it ready for payment? Both meanings are correct. DDD does not ask you to pick one. It asks you to be explicit about which context you are in.

Ubiquitous language: the negotiated vocabulary

Inside each bounded context, there is a ubiquitous language (the shared vocabulary — agreed on by both business experts and engineers — that is used consistently in conversations, documents, and code). The word "ubiquitous" just means "everywhere" — this language appears in meetings, in written requirements, in system documentation, and in the code itself.

Eric Evans, who introduced this idea in his 2003 book Domain-Driven Design, was clear on one thing: the language has to be negotiated between business and engineering, not handed down by either side alone. Engineers bring precision; business experts bring accuracy. Together you arrive at terms that are both precise enough to build software with and accurate enough to reflect how the business actually works.

When Meridian's Underwriting team and their engineers agree that "risk score" means a numerical assessment between 0 and 100 calculated at the point of quote submission, that term appears in every conversation, every document, and every piece of code. Engineers do not invent their own internal names that no one in the business recognises. Business experts do not use vague phrases that engineers cannot build against.

Domain events: what happened in the business

A domain event (something significant that happened in the business, written in past tense — the central building block of event storming) is a record of a meaningful business moment. "Policy Issued." "Claim Filed." "Premium Collected." Notice the past tense: these things have already happened. They are facts, not actions.

The past tense is deliberate. It forces precision. "Submit claim" is ambiguous — does it mean the customer submitted it, or the system processed it? "Claim Submitted" is unambiguous. Something happened. It is done. You can point to it.

Domain events matter for this module because they are the building block of the next technique you will learn. In Module 03, event storming uses domain events as the starting point for mapping an entire business process. If you walk into that session knowing what a domain event is, you will contribute immediately instead of spending the first half hour catching up.

Subdomain types: where to invest your best people

Not all parts of a business deserve equal investment. DDD introduces three categories:

  • Core domain: the part of the business that provides competitive advantage — what makes you different from your competitors. At Meridian, this is underwriting (deciding who to insure and at what price). This is where you put your best people and build the most thoughtful software. Buying an off-the-shelf underwriting engine would hand your competitive edge to a vendor.

  • Supporting domain: necessary for the business to function, but not a differentiator. At Meridian, claims processing is a supporting domain. Every insurer processes claims; doing it well is table stakes, not a market advantage. You still need to build it well, but you do not need to invent novel approaches.

  • Generic domain: standard, commodity functionality that any company needs and that you should almost certainly buy rather than build. At Meridian, billing and invoicing is the generic domain. Generating invoices and collecting premiums is standard logic. A third-party billing platform handles this better and more cheaply than any custom-built system would.

This classification is a resource allocation decision. It tells you where custom investment pays off and where off-the-shelf solutions serve you better.

A note on context maps

Bounded contexts do not stand alone. They depend on each other, hand data back and forth, and sometimes conflict. In Module 04 we will see how to draw the relationships between bounded contexts in a context map (a visual sketch showing the relationships and handoffs between bounded contexts; who owns what, who depends on whom, where translation occurs). For now, just know that once you have named your bounded contexts, the next logical step is mapping how they connect.

Concrete Example

Let's walk through how DDD vocabulary applies to Meridian Insurance launching its new small business property product.

The domain is clear: small business property insurance. This is the territory Meridian is mapping. Four teams operate within it: Sales, Underwriting, Claims, and Engineering.

Three subdomains emerge:

  1. Underwriting is the core domain. Meridian's competitive advantage is its ability to price risk accurately for small businesses — assessing a bakery differently from a landscaping firm, accounting for location, equipment value, and liability exposure. This capability is what makes Meridian worth choosing over a competitor. Engineering investment here is justified.

  2. Claims processing is the supporting domain. Every insurer needs a claims process. Meridian's process needs to be efficient and fair, but the way it handles claims is not the reason a small business owner chooses Meridian over a competitor. Good enough is the right standard here.

  3. Billing is the generic domain. Generating premium invoices and processing payments is standard functionality. Meridian uses a third-party billing platform. There is no competitive reason to build this in-house.

Two bounded contexts with distinct ubiquitous languages:

The Policy Context (owned by Underwriting) has its own language:

  • "Risk score" — a numerical assessment of the applicant's likelihood of making a claim
  • "Coverage decision" — the underwriter's verdict: approved, declined, or referred
  • "Adverse event" — a historical incident in the applicant's record that affects pricing
  • "Approval" — the underwriter's sign-off that a policy can be issued

The Claims Context (owned by Claims) has its own language:

  • "Incident" — the event that gives rise to a claim
  • "Settlement" — the agreed payment to resolve a claim
  • "Adjuster assessment" — the claims adjuster's evaluation of the incident and damages
  • "Approval" — the authorisation to release a settlement payment

Notice that "approval" appears in both contexts with entirely different meanings. In the Policy Context, it is about whether a business qualifies for coverage. In the Claims Context, it is about whether a payment is authorised. DDD says both meanings are legitimate. The goal is not to pick one — it is to always know which context you are operating in.

When Meridian's engineers built the original "approval" workflow using what Underwriting meant by the term, Sales and Claims had unmet expectations. DDD vocabulary would have surfaced this conflict long before a line of code was written, because the teams would have been forced to specify: which bounded context are we talking about?

Analogy

Think of a restaurant kitchen with a head chef, a saucier, and a pastry chef, each running their own station.

The pastry station has its own language: "temper the chocolate," "proof the dough," "crumb structure." The sauce station has its own language: "reduce the stock," "emulsify the butter," "monter au beurre." These stations are bounded contexts. The pastry chef and the saucier use different vocabularies — and that is not a problem. It would be strange and unhelpful to insist they use the same words for everything.

The restaurant's reputation depends most on the head chef's signature dishes — the core domain. The bread comes from a local bakery — generic domain. The expediter makes sure orders flow correctly between stations — that is the context map at work.

The ubiquitous language is the vocabulary that the head chef, the restaurant manager, and the wait staff all share for ingredients, temperatures, and plating standards. When the manager says "the halibut needs to be at 145°F," everyone knows exactly what that means and no one has to translate.

Now imagine if the pastry chef and the saucier were forced to share a single unified vocabulary for everything. Either the pastry terms would lose precision ("temper" becomes "heat slowly"?) or the sauce terms would become meaningless. Forcing one language on the whole kitchen would make the kitchen worse, not better.

That is why DDD says: name the boundaries, define the languages within them, and build translation mechanisms at the edges — do not flatten everything into one model.

Going Deeper

The language belongs to business, not to engineering

One of Evans's most important insights was that the ubiquitous language cannot be invented by engineers and handed to the business. It has to be discovered together, through sustained conversation. Engineers bring precision — they know what the software can and cannot represent. Business experts bring accuracy — they know what the words actually mean in practice, in the messy reality of the business. The language that emerges from that conversation is more robust than anything either side would produce alone.

This has a practical implication for you as a business owner: your participation is not optional. If you hand requirements to engineering and walk away, the language that ends up in the code will be engineering's best guess at what you meant. That gap compounds over time. Every new feature built on an inaccurate language model is harder to get right.

Language drift is a real risk

Ubiquitous language is not a one-time artefact. Businesses change. Terms evolve. What "risk score" meant when the system was first built might not be what it means today if Meridian has changed its underwriting model. If the language in code does not keep pace with the language in the business, you accumulate what DDD practitioners call a "big ball of mud" — a system where no one is quite sure what anything means anymore.

This is why DDD practitioners treat the language as a living document, not a glossary that gets written once and forgotten.

When bounded context boundaries should follow team boundaries

Conway's Law — the observation that systems tend to mirror the communication structure of the organisations that build them — suggests that bounded contexts often should align with team boundaries. If Underwriting and Claims are separate teams, they will naturally evolve separate vocabularies and separate systems. DDD formalises what would happen anyway and makes it intentional rather than accidental.

Common Misconceptions

Misconception 1: "If we use DDD vocabulary, we should have one unified model for the whole company."

This is the opposite of what DDD says. The whole point of bounded contexts is that different parts of the business have different models, different languages, and different rules — and that is not a bug, it is a feature. A "customer" in Sales (a prospect to be converted) is genuinely different from a "customer" in Billing (an account holder to be invoiced). Forcing one definition on both teams would either make the Sales definition too narrow or the Billing definition too vague. DDD asks you to name the difference explicitly, not erase it.

Misconception 2: "DDD vocabulary is something engineers learn and then teach to business. It's a technical thing."

DDD vocabulary emerges from conversations between business experts and engineers. Business owns the domain knowledge; engineers own the implementation constraints. Neither side can produce the vocabulary alone. A business owner who treats DDD vocabulary as "the engineers' job" will find that the software reflects how engineers imagined the business works, not how it actually works. Your participation in shaping the ubiquitous language is what makes the software accurate.

Misconception 3: "Domain events are just system events or log entries."

Domain events describe things that happened in the business, not things that happened in a computer. "Policy Issued" is a domain event. "Database record updated" is not. The distinction matters because domain events are the vocabulary of business processes — they are what you talk about in a board meeting or a customer conversation. When you use domain events as the building block of a process map (which is exactly what Module 03 covers), you stay anchored to business reality rather than drifting into technical plumbing.

Check Your Understanding

  1. At Meridian Insurance, the Claims team calls a person who files a claim a "claimant." The Sales team calls the same person a "client." Should the company pick one term and enforce it everywhere?

    Reveal answer No — and this is precisely the point. Both terms are correct within their respective bounded contexts. "Client" reflects the Sales team's relationship with that person (someone they are serving and retaining). "Claimant" reflects the Claims team's relationship (someone who has experienced a loss and is seeking payment). Forcing one term on both contexts would either make Sales sound clinical or make Claims sound like a marketing department. DDD asks you to name the bounded contexts, define the terms within each, and build explicit translation mechanisms at the handoff points — not to flatten the difference.

  2. Meridian is considering building its own billing and invoicing system from scratch rather than buying a third-party platform. Using the subdomain classification, how would you advise them?

    Reveal answer Billing is a generic domain at Meridian — standard invoice-and-payment logic that any company needs and that provides no competitive advantage. DDD's guidance is clear: generic domains should almost always be bought off-the-shelf, not built in-house. Building a custom billing system would consume engineering time and money that could be invested in underwriting (the core domain, where Meridian's competitive advantage lives). Unless Meridian's billing needs are genuinely unusual in a way no vendor can address, buying is the right call.

  3. Why are domain events written in the past tense rather than as commands or actions?

    Reveal answer The past tense marks a domain event as a fact — something that has already happened and cannot be undone. "Claim Filed" is unambiguous: it happened. "File Claim" is a command — it describes an instruction, not a fact. "Claim Filing" is a process noun — it describes an activity in progress. The past tense forces precision and eliminates ambiguity about whether the thing has happened yet. It also makes domain events useful as audit records: you can trace the history of a business process by reading the events in sequence.

  4. A colleague says: "We've agreed on a ubiquitous language for our whole company — we wrote it all down in a glossary two years ago." What question would you ask them?

    Reveal answer "Has it been updated since?" Ubiquitous language is a living vocabulary, not a static document. Businesses evolve: new products, new regulations, new team structures. If the language in the glossary — and in the code — has not kept pace with how the business actually talks today, it has drifted into a historical artefact rather than a shared working vocabulary. The value of ubiquitous language comes from its continuous use and refinement, not from the fact that it was written down once.

  5. You are about to kick off a new software project. Someone proposes: "Let's skip the vocabulary work and just start building — we can align on terminology as we go." What is the risk they are underestimating?

    Reveal answer The cost of terminology drift compounds over time. Every feature built on an ambiguous or misaligned vocabulary is harder to change later — the misunderstanding is baked into the data model, the code structure, and the documentation. The "approval" ambiguity at Meridian cost three months of rework. That rework happened because the vocabulary problem was not surfaced at the start. Spending time on ubiquitous language and bounded context definition at the beginning of a project is almost always cheaper than retrofitting clarity after the system is built.

Key Takeaways

  • A domain is the business territory your software is built to support. A bounded context is a clearly defined area within that territory where one consistent vocabulary applies. A ubiquitous language is the shared vocabulary negotiated between business experts and engineers that appears in conversations, documents, and code.
  • Different bounded contexts can — and should — use the same word differently. The goal is not one unified company-wide vocabulary but explicit, well-named vocabularies within each bounded context.
  • Subdomains come in three types: core (competitive advantage — invest heavily), supporting (necessary but not differentiating — build competently), and generic (commodity — buy off-the-shelf). This classification is a resource allocation tool.
  • A domain event is something significant that happened in the business, written in past tense. It is the building block of event storming (Module 03), so arriving at that module with a clear definition of domain events will pay off immediately.
  • Ubiquitous language is a business accountability tool, not just an engineering concept. Business owners who do not participate in shaping it will find that the software does not reflect how they actually work.

References