Skip to main content

Foundationbeginner

Supporting Domain

Overview​

A supporting domain is necessary for the business to function, is specific enough that there is no off-the-shelf solution, and does not differentiate the company from anyone.

The decision it demands is the hardest of the three: build, but build simply — and resist the temptation to do it too well.

The Problem​

Supporting domains are most of the system in most companies, and the place where the most effort is wasted.

The mechanism is predictable. A competent engineer works in a supporting subdomain. They see legitimate opportunities for improvement: abstract here, generalize there, make that configurable.

Each improvement is defensible in isolation. The accumulation produces an elaborate subsystem that solves very well a problem that differentiates the company in no way — while the core gets less attention.

It is not a lack of competence. It is the absence of a criterion saying "here, good enough is the target".

Core Concepts​

Good enough is the target, explicitly​

In the core, the pursuit of quality pays off. In a supporting domain, it has rapidly diminishing returns.

That has to be said out loud, because it runs against professional instinct. An engineer who delivers a simple solution in a supporting domain did the right work, and without the stated criterion it may look like they did less.

Do not apply tactical DDD here​

Aggregates, value objects, repositories, domain events — the tactical ceremony costs and only pays off where the rules are genuinely complex and change frequently.

In a supporting domain, a direct service with data access is usually the correct answer. See tactical DDD.

Candidates to become generic​

A supporting domain today may become generic tomorrow, when someone launches a product that solves it.

It is worth monitoring: contract management, expense approval, role-based access control — all were supporting in many companies and today have mature market solutions.

Where to allocate people​

Supporting domains are usually good places for people early in their careers: the problem is real and the learning is genuine. The condition is the blast radius — where compliance, money or irreversible data is involved, the consequence is not contained, and the classification does not change that.

Allocating the most experienced engineers there is the symptom of the misalignment the classification exists to correct.

Why This Matters​

Because it is most of the system. What you decide about supporting domains determines where most of the effort goes.

Because it gives permission for simplicity. Without the label, an engineer has no argument for delivering the simple solution. With it, they do.

Because it frees capacity for the core. Every month not spent elaborating a supporting domain is a month available where it matters.

Common Mistakes​

Applying tactical DDD. The most common mistake and the most expensive in volume.

Allocating the best engineers.

Generalizing preventively. See YAGNI. A supporting domain rarely needs to absorb future variation.

Not reassessing whether it became generic.

Treating it as core out of attachment. Teams that worked for years in a subdomain tend to defend it as strategic.

Real-World Example​

A fintech had a document management subdomain: upload, categorization, expiry validation, retention according to regulatory rules.

Necessary — without it there is no compliance. Specific — the retention rules come from sector regulation and no off-the-shelf product implemented them. Differentiating? No — no customer chose the fintech because of its document management.

Supporting, therefore.

What the team had built in two years: a configurable workflow engine, with retention rules declared in a bespoke language, document versioning, and an admin interface for creating new document types.

Four engineers, eighteen months.

The actual usage: eleven document types, created in the first month and never changed since. The configurable engine was never configured after the initial load.

Rewriting it as direct code — eleven types as constants, retention rules as code, no admin interface — took six weeks and removed 80% of the code.

The team was reallocated to the core, which was credit risk assessment.

The mistake was not technical. The configurable engine was well built. The mistake was building it in a place where flexibility had no value — and nobody had said so.

The degeneration pattern​

Supporting subdomains degenerate predictably, and recognizing the pattern allows stopping it early.

Phase one — the direct solution. Someone implements what is necessary, simply. It works.

Phase two — the first exception. An unforeseen case appears. Instead of treating it as a case, someone generalizes: adds a parameter, makes it configurable.

Phase three — the platform. More exceptions arrive. The generalization becomes a mechanism: a small configuration language, a rules engine, an admin interface.

Phase four — permanent maintenance. The mechanism needs someone who understands it. It has defects of its own, documentation of its own, and a learning curve for newcomers.

The most effective intervention is at phase two: treating the first exception as an exception, with an explicit if and a comment, rather than generalizing.

That looks less elegant and is the correct decision in a supporting domain. Elegance has value where flexibility has value — and there it does not.

Practical Exercise​

Pick a supporting subdomain in your system and count how many configuration or extension points it has.

For each, check how many distinct values have been used since it existed. The ones with only one are flexibility that was never exercised.

Interview Questions​

  • What characterizes a supporting domain?
  • Why not apply tactical DDD here?
  • How do you recognize that a supporting domain became generic?

Further Exploration​

  • Evans, Eric. Domain-Driven Design. Addison-Wesley, 2003.
  • Vernon, Vaughn. Domain-Driven Design Distilled. Addison-Wesley, 2016.
Finished reading this document?Your progress is saved in this browser only.