Domain Modeling Heuristics #1: I See Users Everywhere!

This begins a series of articles where I’ll explore various heuristics I’ve collected or discovered myself. These heuristics are for uncovering where boundaries in your software could/should/ought to be and tools for facilitating insights and what DDD practitioners call “breakthroughs.”

[Breakthroughs are] the most important insights [that] come abruptly and send a shock through the project… [it] is not a technique; it is an event.

Domain Driven Design (The Blue Book), Chapter 8

Building software that tackles problems that are themselves complex, or that exist within a complex environment is not easy. That’s where domain-driven design comes in.

Ideally, you should be familiar with domain-driven design to follow this series. But, if you aren’t, perhaps the articles in this series would help to clarify what DDD is all about 🤷‍♂️.

Users Everywhere…

As you explore designing your software and understanding the real business context that you need to solve problems for, you find that certain concepts keep appearing.

This could be during the design phase: while discovering requirements, extracting knowledge from domain experts, during event storming sessions, etc. This can also occur while building the software itself.

For example, there are moments during a software project when you realize that there’s a piece of code – an object or collection of data – that is needed in many parts of your system. You think to yourself, “should I create a way to share this object throughout my code?”

The classic example of this is the User. The User appears everywhere in your system! No matter how you slice and dice your code and explore the domain, the User is to be found…

This domain concept seems to have reared its head into every other part of the system.

One pain that you may find yourself having is that you’ve created a God class that every part of your system needs. Or, you just know something’s not right about how this concept is used everywhere.

When exploring the domain with domain experts, they seem to always have different opinions about the User too…

Insight

You know that this is a core concept of the system – nothing would work without it.

The reason why it keeps rearing its head everywhere is that it truly exists within multiple contexts (and you just thought, “Thanks, captain obvious!”).

The next step is to figure out how this concept is treated by different areas of the business.

Let’s look at another example.

I See Patient Everywhere!

Think of a medical practitioner’s domain. There are patients…everywhere. Patients in the schedule, patients in the waiting rooms, patients working with the doctor, patients being referred to specialists, etc.

The mistake we software developers often make is to make a shared Patient model for our entire system to use. Software developers are addicted to code reuse. However, it’s at the cost of not isolating our domain models and establishing boundaries.

In domain-driven systems, we want to split up these kinds of objects. Different areas of the business that are translated into our software should address only the specific problems and representation of that domain. We want to avoid polluting our designs and solutions with those of other areas of the business. This keeps our domain model simpler, and easier to reason about. Therefore, this (usually) makes our code simpler and easier to reason about.

Whenever you discover a domain concept that is found everywhere you look, your “spidey sense” should start tingling! This might be a significant key to unlocking context boundaries for this domain.

Domain Movement

With our Patient example, we see that this “thing” is moving through various parts of our domain. Patient is moving from one physical location to another. Patient is even found in the schedule.

Another heuristic for discovering boundaries revolves around discovering objects that move through stages, and locations or are passed from one place, person, team, department, etc. to another.

For example, an insurance application is passed on from the broker to the underwriter.

A mortgage application is passed on from the broker to the solicitor – then ultimately to the bank/servicer.

Note: I’ll probably write more about this specific heuristic in the future.

The bottom line for this insight is that anytime you see some domain object poking its head up in various places – it’s probably a good candidate to explore where boundaries in your system are.

Apply It!

Here are some tips to take this discovery and move forward with it:

• Focus your discussions with domain experts specifically around this concept.
• Use the domain events generated by this object to become points of discussion.
  • Do any of these events represent pivotal changes in how that object is viewed or used?
  • Do any of these domain events trigger processes that you’ve already decided ought to exist in a bounded context?
  • Are any of these events representing a change in who or what owns it?
• Much like the User, explore whether different areas of the business actually call this object by different names (e.g. Customer, Client, Employee, Applicant, etc.)