2.4 Domain modeling

Before beginning domain modeling, make sure we are ready to proceed. Our definition of ready aligns us for success, and as usual we’ll take a moment here to make sure we have everything we need.

Before starting

Domain modeling identifies independent domains in your business — spheres of knowledge that are fully or loosely decoupled from each other. It’s an aspect of domain driven design that defends against poorly understood architectures. By grouping related entities, language and workflows inside bounded contexts, you create cleaner APIs, simpler components, and a shared vocabulary between business and technology.¹

The DoR draws on event maps from 2.3 Strategic event storming, personas from 2.1 Product strategy, and use cases from 1.4 Business capabilities & functions — finish any that are outstanding.

Guide to domain modeling

Before diving in, establish a few important “terms of art”:

1. Domain. A collection of related concepts, relationships, and workflows.²
2. Domain model. A system that describes the selected aspects of a domain and that is often used to solve problems related to that particular domain.
3. Domain logic (also, “business logic”). The unique value of your application — the purpose and rules that implement your processes. It’s where your business processes are codified, defining how data is handled.
4. Entities. The unique and identifiable representation of things in our domain: A combination of behavior and data. A customer, an account, and a merchant are all good examples of entities.
5. Bounded context. A bounded context is what knits together a collection of related entities, data, behaviors and their ubiquitous language into a related model. It creates a boundary inside of which we want consistency: Everything inside the boundary needs to be closely related, and share the same ubiquitous language.
6. Ubiquitous language. Our agreed-upon terminology that applies within a given bounded context. Ubiquitous language changes as we shift from one context to another — for instance, the way the word “account” means something different to a customer versus an underwriting agent.

A word on ubiquitous language

Ubiquitous language is agreed-upon terminology everyone uses in all aspects of the design and development process (including the code, which also uses ubiquitous language terminology). It is absolutely necessary, because disruptions in language will lead to misinterpretations, misunderstandings and often outright mistakes. This happens because domain experts have and use their own jargon. Technology professionals do exactly the same. This creates a gap between the business and technology in daily discussions — and that leads to mistakes.

On the other hand, by creating a shared vocabulary and eschewing any terms that don’t fit into that vocabulary, the team as a whole communicates effectively. But that means it’s crucial to follow your ubiquitous language — and constantly stay away from non-business terms. This can be hard (which is why I wrote about it at length) — but it’s critical.

I use a simple rule: If it’s a word the business domain expert doesn’t understand, don’t use it. Ask them, “what would you call this?” Use that term everywhere, in documentation, designs, technical artifacts, even in the code.

Goals and impact

Returning to our core use case, we pick up where we left off by taking our event map from chapter 2.3 Strategic event storming, and adding domain boundaries to the map.

We do this by grouping functional capabilities and dependencies together into their domain. This might require us to reorganize our event map a bit — that’s fine. In fact, that’s a good thing because it indicates that we are starting to collect closely related capabilities together.

Each functional domain’s area of influence is added to the event map, indicated by dotted boxes. These domains are separated by contextual boundaries or “bounded contexts.” Every business domain will start as its own bounded context. Over time we’ll start to create smaller, more fine-grained bounded contexts, essentially subdividing a domain into smaller, independent pieces — but for now, just focus on identifying your core business domains.

Look for changes in context, changes in your ubiquitous language, as you move from one component to another. These changes are a good indicator that you’ve left one domain, and entered another. For instance, in the customer context, an “account” relates to that customer’s account with the bank. But as we transition to the loan context, it takes on a different meaning: “account” in the loan context means a specific debt associated with a particular loan number. These are different bounded contexts, which we model on our event map.

As you map your domains, provide detailed descriptions of each so all parties are aligned on the domain’s responsibilities. Expand on your event map by developing a domain model that shows each separate business domain, and the entities (or business capabilities, behavior and data) of each.

Tips

A few things to keep in mind when defining your domains, and their bounded contexts (a domain is just a high-level bounded context):

• Each bounded context focuses on a single, core responsibility.
• The goal is to drive simplicity, making your domains (and each bounded context) less complicated. Use subdomains to do this.
• Each context should have a single top-level entity. These are called aggregate roots. For instance, the “customer” context might use its “account” entity as its aggregate root. (It would be fine for the “customer” context to have a “customer” aggregate root).
• Everything related to a bounded context is linked “under” its aggregate root. (That’s why they are called “aggregate roots,” they aggregate everything else under them).
• Make sure that each bounded context has exactly one aggregate root. If you need two, you probably want two separate bounded contexts.

Inputs

To begin domain mapping, you’ll need several artifacts that were created in previous activities:

• Sufficient event maps to document the use cases of at least one user journey.
• Detailed personas and use cases for each event map.
• A dictionary of ubiquitous language (that will continue to evolve).

Process

This is a group activity and requires your whole team to be effective. Most important, your business domain experts, product owner, and technology team members need to be present.

Preparation

Be sure that everyone is well prepared, and has a clear understanding of the purpose of this workshop: If this is the first time you’ve done a domain mapping activity, you may want to schedule some time at the beginning for a rehearsal.

Set a clear agenda as well. I like to share specific event maps with the working group ahead of time, establishing clear scope for the workshop. It’s a good idea to set a time box so that everyone is prepared to dedicate appropriate time and attention.

Execution

Using a collaborative, workshop style, guide the team in building your domain model. Work through your event maps, creating the following domain model artifacts as you go:

1. Domain descriptions. 2–5 sentences describing each domain with clear business language. Remember to ground the language in your agreed-upon ubiquitous language.
2. Bounded contexts. Itemize bounded contexts for each domain (this will probably not be exhaustive, since your contexts will continue to evolve).
3. Define responsibilities. Each context must include a list of responsibilities that are independent to that context, and not overlapping any other context.

I like to develop my domain model using a diagramming tool such as Miro. Domains are initially identified on your event map using dotted boxes. You can then model each domain as a bubble to represent that domain’s bounded context. As your model evolves, feel free to break domains into completely separate bounded contexts or subdomains, as appropriate.

Each bounded context will define its responsibilities. Simply add specific responsibilities inside the context bubble to denote the entities that “live” within that context. I use a box with a dotted line to represent a reference to another context (usually implemented as “value objects,” because they lack identity — they solely represent a reference to data of another context).

Remember that there can only be one source of truth for any single entity or data element in the system. This means that each entity needs to live in a unique context. You can reference it from another context, but don’t put one entity inside multiple bounded contexts (use a value object instead).

Outputs

• Domain map. A visual representation of the identified business domains.
• Domain descriptions. Detailed domain and bounded context descriptions.
• Context list. At least one context for each domain.

In the next chapter, 2.5 Context mapping, we’ll explore how contexts interact with each other. We’ll focus on creating greater efficiencies — efficiency of scale, efficient APIs, and clean (efficient) data models that don’t share unnecessary information.

If you’d like to learn more about domain driven design, Domain Driven Design Distilled by Vaughn Vernon is a quick read and will get you up the learning curve in a weekend.³

Templates

• Domain detail template

Next activity

• 2.5 Context mapping

Other references

• Ellis Andrews, Domain Modeling by Example: Associating Objects with Python.
• Oleg Chursin, A Brief Introduction to Domain Modeling.