2.4 Domain modeling
Domain modeling creates the foundation for your product architecture. It ensures your design is carefully crafted, fits the business purpose, and drives both technical and team efficiency.
Introduction
Would you want to fly in an aircraft that was built by someone who never flew a plane or worked in the aeronautics industry? How would you feel about it if you knew they never took the time to learn much of anything about airplanes, flight dynamics, or flight systems? If they just “coded up a solution” based on specifications they were handed?
Unfortunately, teams routinely build software without taking the time to develop a deep understanding of the business space they’re working in. It’s a particular problem for consulting agencies, where the incentive is to staff a team, get them profitable, and then rotate to a new project (and a new business domain) as quickly as possible.
In this chapter we’ll explore domain modeling. It’s an aspect of domain driven design that defends against poorly thought out, poorly understood architectures. It does so by creating greater depth of understanding and clarity in the design phase.1
Remember, domain driven design is not about technology — it’s about understanding and modeling the business. It’s very effective at ensuring your business and technology are aligned.
I especially like this quote about the value of domain driven design:
“Put another way, domain-driven design is a system of collaboration, enabling technical and non-technical contributors (such as subject-matter experts) to communicate and understand each other, to the ultimate benefit of the product being created.”2
What kind of team do you have?
In my experience, when it comes to the design phase there are two fundamentally different kinds of teams:
There are teams that think of an application as code. It’s something that can be specified, and you can build it by following sufficient specifications. Truly understanding the business is unnecessary.
Other teams believe an application is the realization of a business’ mission. These teams understand that without building deep, contextual awareness of the business itself, the application will fall short of its goals.
It’s the difference between blindly following specifications, versus building a critical understanding of a product before trying to build it. Learn how to fly, actually fly a plane, then build one — not the other way around.
Domain driven design emphasizes developing a full view of the application design. This means learning the business, not just the technical specifications “to be delivered.”
Your product’s domain is basically the subject area that your product addresses and/or operates within. It includes the user requirements the product aims to fulfill, the business goals it will contribute to, and the terminology used to describe and discuss it. The domain then influences more technical issues, such as programming languages, the devices and other hardware to be used, and of course, the programmed code, functions, and features of the product itself. The more complex the product and its domain are, the more important it is to include all elements of that domain in the design and development process.”3
Teams that don’t embrace the idea that design is not just about fulfilling specifications will run headlong into risky territory. More often than not, those technical specifications will start to diverge from intended business purposes. This is not surprising: If technology and business knowledge are treated as two separate, unconnected things, then what guardrails will keep them in synchronicity?
If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!
Keep reading with a 7-day free trial
Subscribe to Customer Obsessed Engineering to keep reading this post and get 7 days of free access to the full post archives.