Skip to main content

Understanding Pure Domain Modelling: Bridging the Gap Between Existing Systems and the Real Domain

Domain modelling plays a crucial role in the way that I design systems to reflect the business's needs and processes. However, I experienced there is often a disconnect between the idealistic view of domain modelling and the practical reality faced by domain experts. One key issue is that domain experts tend to start from their existing systems rather than describing the 'real' domain.


In this post I want to talk about pure domain modelling as a way to overcome the bias that domain experts have when explaining their needs.

The domain expert bias

When domain experts contribute to domain modelling, they frequently start from the perspective of the existing systems they are familiar with. These systems, whether they are legacy products, databases, or other technological solutions, shape their understanding and descriptions of the domain. While this approach has its advantages, it also introduces several challenges:

  • Bias Towards Existing Systems: Domain experts may describe the domain in terms of how it is implemented in the current system rather than how it truly operates. This can lead to models that are overly constrained by the limitations and design choices of existing systems.
  • Overlooked Business Rules: Important business rules and processes that are not well-represented in existing systems may be overlooked. Domain experts might inadvertently omit details that are crucial for a comprehensive domain model.
  • Resistance to Change: There can be resistance to adopting new models that deviate significantly from existing systems. Domain experts may be more comfortable with familiar structures and processes, even if they are suboptimal.

Remark: It is important to understand that these challenges exist when talking to domain experts. I’ve spend a full workshop with business creating a domain modelling where at the end I discovered we just had modelled the existing system and didn’t capture the real business needs.

Users don’t describe requirements, they describe workarounds. – Udi Dahan

What is Pure Domain Modelling?

Pure domain modelling refers to the process of creating a conceptual model of the domain that is as close to reality as possible. It involves understanding the core business processes, rules, and entities without being influenced by existing systems or technologies. The goal is to capture the essence of the domain in a way that is both accurate and understandable.

To create effective domain models, it is essential to bridge the gap between the practical reality of existing systems and the ideal of pure domain modelling. Here are some strategies to achieve this:

  • Educate and Collaborate: Educate domain experts about the principles of pure domain modelling and the importance of capturing the true essence of the domain. Encourage collaboration between domain experts and developers to ensure a shared understanding of the domain's core aspects.
  • Use Interviews and Workshops: Conduct interviews and workshops that focus on understanding the business processes and rules independently of existing systems. Ask domain experts to describe the domain as if no systems were in place, highlighting the 'why' behind each process and rule.
  • Identify and Document Assumptions: Identify and document assumptions made based on existing systems. Challenge these assumptions and explore alternative ways to represent the domain. This can help uncover hidden aspects of the domain that are not well-represented in current systems.
  • Incremental Modelling: Adopt an incremental approach to domain modelling. Start with high-level concepts and progressively refine the model by incorporating more details. This allows domain experts to gradually transition from system-based thinking to a more domain-centric perspective.
  • Leverage Domain-Driven Design (DDD) Practices: Utilize Domain-Driven Design (DDD) practices to facilitate the creation of pure domain models. Techniques such as Event Storming and the use of ubiquitous language can help align the model with the true nature of the domain.

Take away

The tendency of domain experts to start from existing systems rather than the 'real' domain can pose significant challenges. By recognizing this tendency and employing strategies to bridge the gap, it is possible to create domain models that are both realistic and beneficial. A key question I always ask during domain modelling workshops is:

What would you do if there was no system available?

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more