Learning paths
The hub holds the model. The Academy teaches you how anyone arrived at it.
Seven paths through domain-driven analysis, in the order the work runs: learn to hear a domain in the words people already use, work out which parts of it are worth your best people, draw the boundaries, model inside them, follow a process that crosses three of them — and only then take the path that needs everything above it, which is checking any of it against the systems that are actually running.
In preparation.The curriculum below is settled; the lessons are still being written, and there is nothing to enrol in yet. Every path links to the documentation that covers its ground today.
Told as stories
Domain-driven design is taught badly as a vocabulary and well as a sequence of arguments somebody had to settle. Nobody has ever been helped by a definition of "aggregate"; people are helped by watching one get drawn in the wrong place and finding out what that cost. So the lessons carrying astorymark come with a short video in narrative form: a team with a problem, the option they took, what it bought them and what it cost. 16 of the 38 lessons are planned that way — the rest are short enough to read.
The curriculum
- FoundationComing soon
Listening for the domain
Before any modelling: how to hear what the business is actually saying. Where the words differ between two rooms, where one word is doing four jobs, and why the exceptions people apologise for are usually the model.
- The word that meant three things and cost a release Includes a storytelling video
- Ubiquitous language: not jargon, not glossary, not a data dictionary
- Interviewing for the model rather than for the requirement
- The exception is not an exception — it is the rule you have not found yet Includes a storytelling video
- Writing a term down so that two teams recognise it
Read today: Ubiquitous language
- FoundationComing soon
Domains, subdomains and where the value is
The distinction that decides where the effort goes. Core, supporting and generic are not a taxonomy exercise: they are a budget, and getting one wrong is how a company builds its own invoicing and buys its own competitive advantage.
- Problem space and solution space, and why conflating them hurts Includes a storytelling video
- Finding subdomains: follow the money, the org chart and the arguments
- Core, supporting, generic — and what each one deserves
- The company that outsourced its core domain Includes a storytelling video
- When a supporting subdomain quietly becomes core
Read today: Domains and subdomains
- CoreComing soon
Drawing bounded contexts
A boundary inside which one model holds and one word means one thing. This path is about where to put the line, how to know you put it wrong, and how to resist the urge to have one canonical model of everything.
- What a bounded context actually bounds Includes a storytelling video
- The canonical data model, and why it never survives contact
- Signals that a boundary is in the wrong place
- Contexts are not microservices, teams or databases — but they interact with all three
- Splitting a context that grew two languages Includes a storytelling video
Read today: Bounded contexts
- CoreComing soon
The domain model, for analysts
Entities, value objects, aggregates and events, explained as business concepts rather than as class stereotypes. An analyst who can say where the invariant lives can hold a design conversation that a use-case document never opens.
- Identity versus value, and the question that separates them
- An aggregate is a rule with a boundary drawn around it Includes a storytelling video
- Invariants: the sentences the business will not let be false
- Domain events as the business’s own record of what happened
- When the model disagrees with the form on the screen Includes a storytelling video
- Modelling in the room with the developers, not before them
Read today: The domain model
- AppliedComing soon
Business processes across contexts
Event storming from first sticky note to an agreed model, and what happens to a process that crosses three boundaries: no shared transaction, no single owner, and consistency that has to be negotiated rather than assumed.
- Running your first event storming session Includes a storytelling video
- From orange stickies to a process everyone recognises
- Commands, policies, read models — the four-part sentence
- Orchestration or choreography, and who gets to decide
- Eventual consistency explained to someone who signs off on it Includes a storytelling video
- The compensating action nobody designed Includes a storytelling video
Read today: Business processes
- AppliedComing soon
Cataloguing and context mapping
Turning what you found into something a second person can use: catalog entries that stay true, and a context map whose arrows carry the political fact — who is upstream, who conforms, and who has an anticorruption layer because they had no choice.
- What belongs in a catalog entry and what rots in one Includes a storytelling video
- Ownership: a context without a named owner is unowned
- The nine relationship patterns and what each one admits to
- Reading a context map for organisational risk rather than technical risk Includes a storytelling video
- Keeping the catalog alive after the consultants leave
Read today: Context mapping patterns
- AdvancedComing soon
System mapping and drift
The half most modelling efforts skip. Observing what the estate actually does, comparing it against the map you drew, and turning the difference into a finding with an owner instead of a slide with a red box on it.
- Evidence over assertion: what a system map may contain Includes a storytelling video
- Collecting it — traffic, schemas, topics, and their blind spots
- The four verdicts: matches, drifts, unmapped, missing
- A breached boundary, traced from a claim payment back to a shared table Includes a storytelling video
- Prioritising drift by what it costs, not by how ugly it is
- Making conformance a standing number rather than an audit Includes a storytelling video
Read today: Conformance and drift
You do not have to wait
Everything the first lessons will teach is already written down, and the fastest way to see how it fits together is to take one word your business argues about — "customer", "policy", "order", "account" — and write down what it means in each of the rooms that uses it. If the answers differ, you have found a boundary, and you found it in an afternoon.