Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
What is the worst mistake you can make when modeling a domain? I was asked this question by a member of my channel on our private Discord. Before giving you my answer, I decided to post this to the community for their take. Here are a few that were interesting and that I’m going to elaborate on and give some more insights into why these are common mistakes when modeling a domain.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Theme
I asked this question on Twitter/X, and got a decent amount of responses.
Many of the responses I thought had a thread or theme to them. So I want to share some of them and provide a bit more detail into some of them from my perspective.
Probably the most common thread is a heavy focus on technology in terms of programming languages, frameworks, libraries and tools, rather than the business problem at hand.
I agree with the following takes, and the thread between them is that there is often a focus that’s too much on the technical side of implementation rather than the what and the why. What are we building and why? What are the problems it’s solving?
I get it. Developers are into tech and love the library of the day and all the hotness. But this is the reason why we end up in a hammer-and-nail situation. We have some tech we want to use and shove into any situation when it doesn’t fit the solution space at all.
A great example of this is Domain-Driven Design. When people first get into it, they immediately latch on to the tactical patterns in code such as Entities, Value Objects, Aggregates, etc. You can find all kinds of tutorials that show you how to use these patterns, but rarely do they ever explain the reasons why you might use them and where they might not be useful.
The moral of the story is that you’ll be better served focusing on the problem at hand and the use cases. Then determine what technical solution fits.
Context is King
Context always matters. When you lose context, everything sounds the same when it isn’t at all. The example above from Roger is a great illustration. there’s a lack of perspective and context and thinking everything is the same because of the language.
The problem you can run into when you fall into this trap is what I call entity services. You end up with “services” responsible for everything to do with a noun, often driven by CRUD. So it turns into noun-driven-development.
In the example above you end up with a DriversLicense service. Rather, in reality, the concept of a Drivers License exists in many different context and can be modelled that way, rather than having one model to try and rule them all.
Especially with Domain-Driven Design, if you’re new to it, it’s easy to get into this trap of over-analysis. Don’t get me wrong, I’m absolutely a fan of discovery and really understanding the domain you’re in, but you have to make progress and move forward.
Only through moving forward will you have “ah-ha!” moments where you realize maybe how you modeled something might not be ideal. Where what you thought was how a business process worked, wasn’t exactly it. Move forward with imperfect information.
As Udi Dahan once wrote, don’t try to model the real world, it doesn’t exist. That might sound strange, but it’s what I was talking about earlier. It’s about perspective. The real world, according to who? You need to take in perspective with context. What the model looks like in one context might differ greatly from another. They might be the same words, but they mean different things and have different utility.
Domain Modeling Mistakes
Don’t start with technical. Start with the domain and the problems you’re trying to solve. Realize that Context is King (as I always say). Not all models will solve all problems, you don’t need one model to rule them all. Evolving your model means moving forward and making progress with imperfect understanding.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.