Domain-driven design

The point of a software system is to be a solution to a business problem. Many systems incur architectural debt before they’re even built by not being in useful dialogue with the business problem they’re supposed to be solutions to.

Domain-driven design provides some useful vocabulary and ways to break down what a business does and how to align that to the architecture you design.

A business domain is an organization’s main area of activity. An organization can have several and they can change often. To identify them, ask:

• What is this organization doing?
• Who are its customers?
• What service or value does the org provide?
• What companies or products is it competing with?

A subdomain is a fine-grained area of business activity. One subdomain is insufficient for success; businesses address a business domain through the product of several subdomains’ interactions. A subdomain is made of a set of interrelated coherent use cases, covering the same actors, business entities, and sets of data.

Core subdomains are what a company does differently from competitors. They are complex (if they weren’t, everybody else would be doing it, too), and require innovation and optimization. They may or may not be technical. To identify them, ask:

• Is there a “secret sauce”?
• What are non-technical competitive advantages?
• What are the worst software components? (Usually these are complex and can’t be replaced, so they get to be in bad shape.)

Generic subdomains are business activities that everybody is doing the same way. No need to innovate here, just meet expectations. These can be complex, like authentication or payment processing. To identify them, ask:

• Where are we using off the shelf software, subscriptions, or open-source solutions?

Supporting subdomains enable core subdomains. They are usually simple, involving straightforward processes like data entry or ETL processes. To identify them, ask:

• Where do we have components that can’t be replaced or bought?
• Where do we have things that haven’t changed in a long time?

Complex areas don’t have clear answers but [[complex systems can be abstracted]] by moving up the ladder of abstraction to make them understandable.

DDD puts a heavy focus on “ubiquitous language,” which library people would probably recognize as “controlled vocabulary.” Controlled vocabularies promote communication because vocabulary is not all-purpose. Controlling vocabulary incurs coordination costs, though, so bounded contexts keep large models usable. Instead of treating everything like one big, nebulous context, divide subdomains into logical contexts and define a collaboration model.

References

Khononov, Vladik. Learning Domain-Driven Design . 1st edition, O’Reilly Media, Inc., 2021.