Skip to content

Domain-driven business analysis

The business already has a model. Most of it is just not written down anywhere.

It lives in the words people use, in the exceptions they apologise for, and in the arguments that never quite resolve because two departments mean different things by the same noun. Domain-driven analysis is the work of finding those boundaries, naming them, and writing down the model that holds inside each one. And then the part that usually gets skipped: checking, continuously, whether the systems anyone actually runs still respect them.

Read the approachBrowse the catalog

Why this hub exists

A catalogue of intent is a diagram. A catalogue checked against the estate is a model.

Most domain modelling stops at the point it becomes valuable. The boundaries get drawn, the workshop ends, the diagram goes into a wiki, and four years later nobody can say which of it is still true. This hub is built around the assumption that the second half is the half worth paying for — so every bounded context here carries the systems that claim to implement it, and every relationship on the context map is checked against an integration somebody observed.

Bounded contexts
9
Across 9 subdomains, of which 3 are core. 5 are modelled to the level of aggregates and invariants; the rest are honest about being a boundary and a name.
Observed integrations
11
Between 9 running systems, each recorded with the evidence that observed it rather than with the memory of the person who drew it.
Findings open
5
Integrations that drift from the model, run without one, or exist on the map with nothing behind them. Each one names what it costs and who can fix it.

Areas

One model, from seven different seats

A domain model is not a document one person owns. It is an agreement that has to mean the same thing to the person who sells the product, the person who builds it and the person who lives with it at three in the morning.

  • “I spent six years writing requirements that were correct and useless. The change was not a new template — it was noticing that the word "policy" meant three different things in three rooms, and that nobody had ever been in all three at once.”

    Business analyst

  • “They asked me what a risk was and I said what everyone says. Then they asked what a risk is once it has been declined, and I realised we had been arguing about that in my department for a decade without knowing it.”

    Underwriter

  • “The catalog did not tell me anything I did not already know about my own area. It told me what the areas next to mine believed, which turned out to be the expensive part.”

    Product owner

  • “Context boundaries stopped being an architecture opinion the moment they had owners with names. An unowned boundary is a suggestion, and suggestions do not survive a deadline.”

    Solution architect

  • “I have never had an analyst hand me an aggregate before. What I got instead, every time, was a screen design and a list of fields, and I had to guess which rules were allowed to be false for a moment.”

    Software developer

  • “We had a beautiful context map and a system nobody had looked at in four years. The map was aspirational, and everyone knew it except the map.”

    Enterprise architect

  • “The reason a claim gets assessed against the wrong cover is not a bug in a screen. It is that two systems disagree about what a policy is on a given date, and until somebody wrote that down as a boundary, we just kept paying for it.”

    Claims handler