What Data Engineers Can Learn from Domain-Driven Design

Data engineers can borrow three ideas from domain-driven design: bounded contexts, a ubiquitous language and domain ownership. Together they keep a pipeline from losing the business meaning of the data it moves.

Domain-driven design (DDD) comes from application software. It asks how to model a business so that code and business talk about the same things. Data work has the same problem, and it usually solves it worse.

The failure DDD is built for

A pipeline can run on time, pass every test and still be wrong. The column is called revenue. Finance means booked revenue. Sales means signed contract value. Both are right in their own world. The dashboard shows one number and both teams distrust it.

This is not a tooling problem. A faster warehouse does not fix it. The meaning was lost somewhere between the source system and the table, and nobody owned that step.

Bounded contexts: one meaning per boundary

A bounded context is a boundary inside which a term has exactly one meaning. Outside it, the same word may mean something else.

In data work, this changes how you draw the platform:

• Model each context on its own. Billing gets a billing model. Support gets a support model.
• Do not force one global customer table to serve everyone. It ends up serving no one well.
• Write the translation between contexts as an explicit, tested step. A mapping from billing customer to support customer is a real piece of the system, with an owner.

The common alternative is one big shared model that grows a column for every team's definition. It looks tidy. It is where meaning goes to die.

Ubiquitous language: names that match the business

DDD asks the team to use the business's words in the code. Not flag_3 or status_cd. The word the people in that domain actually say.

For a pipeline, that means:

• Table and column names come from the domain, not from the source system's schema.
• Each important term has a short written definition next to the model. One or two sentences.
• When the business changes a word, the model changes with it. A rename is a real change, reviewed like any other.

This is cheap. It is also the step most teams skip, because it needs a conversation with a non-engineer.

Domain ownership: someone answers for the meaning

Engineers can run the platform. They cannot decide what 'active user' means. A person in the domain has to own that.

Treat each data product as having two owners with different jobs:

• The platform owner answers for freshness, tests and cost.
• The domain owner answers for what the data means and when the definition changes.

Without the second owner, definitions drift and nobody notices until two reports disagree.

What this looks like in a small team

A team with zero to three data people cannot run a full DDD program. It does not need to. Four small steps are enough:

1. List the five or six terms people argue about. Write one sentence for each.
2. For each term, name the context where that sentence is true.
3. Where two contexts use the same word differently, add an explicit mapping table and a test on it.
4. Put a named person from the business beside each important table.

That is an afternoon of conversations and a few small models. It does not need a new tool.

Where DDD does not fit

DDD is a poor fit for a single-source, single-team dataset with one agreed meaning for everything. There the ceremony costs more than it saves. It also does not replace data quality checks. A well-named column can still be wrong.

If you want a fast outside read on your own platform, I do not need a call to start. The free Data Platform Teardown lets you check it yourself, and it covers ownership and naming among other things.

I work alone, so I take on few engagements. I am not the right fit if you want a large team to run a long program of work on your data model.