Great DDD traits all IT managers should care about
This is for all IT managers wondering what DDD can do for you. I will discuss six traits that will improve your IT organization.
In recent years — parts of — Domain Driven Design (DDD) went from niche to ‘mainstream’. Domains offer the largest ‘separator’ for any platform you might be building. The term ‘domain’ has recently grown from senior-engineering lingo to management-level conversations. Whether this is the application landscape or your data lake. Domain boundaries have become part of enterprise-level conversations about our IT landscape.
Background and origins of domains (can be skipped)
The bubble metaphore. A domain represents a bubble. Just like a social ‘bubble’ it is a small universe on its own. A bubble has its local flavoring. The language we use is understandable mostly to people inside the bubble. If you want to have some interaction with this bubble, you should be prepared to do learn the insider’s language and do some translations.
I believe this is a good metaphor to understand a domain-driven domain. So whenever you hear engineers talking about ‘domains’ think bubble.
Domain-driven design theory comes primarily — but not only — from a famous book: Domain-Driven Design written by Eric Evans in 2003. However, it took some time before the industry found its way to transfer theory to practice. During the past ten years of microservices and cloud, the industry found out that domains help to organize our IT landscape.
I you want more background about DDD. Here is an introductory article aimed at IT managers covering the basics of domain-driven design.
The great traits of DDD for you as a manager
Domains compartmentalize the IT landscape
Domains help to compartmentalize. Just like legal entities in business life protect your company’s resources. This works like a bulkhead in a ship that contains a ‘leak’ to a small compartment.
As a manager, having isolation between different parts of your IT is something you should be happy with. For big changes, you effectively decrease the exposure of your overall IT landscape. Ideally, you contain it to a single team that handles the change. Or sometimes you contain it to a handful of teams working on a single bigger domain. This will keep your IT organization healthy and agile. Despite scaled-agile cross-team coordination frameworks like SAFe, you should prefer features with a low blast radius over coordinating cross-team (and cross-domain).
Domain language creates depth of understanding
Domain-driven design pushed teams to develop a core model (the place where the valuable business rules go) and a shared language with the business. Your engineers should have an expert-level understanding of what happens in the business.
💡 The surgeon metaphore. When working on something really complicated like your heart or your brains, you prefer a cardiologist or a brain surgeon over a general practitioner. The expertise acquired from a huge investment in a small subject matter pays of with less errors and ‘rework’. The work of software programmers has gotten increasingly complicated with modern technology, if you want them to be an expert in understanding the business they need focus.
📝Reflections: In many agile adoptions, you will see teams having a too wide ‘spread’. The term: multidisciplinary is often misused as an excuse to have teams do ‘everything’. However, practically you must choose between breadth or depth of understanding. Especially with complicated business processes, shallow knowledge often leads to lots of rework or unmaintainable spaghetti code. Does this sound familiar to you?
Domains offer a good foundation to structure your teams
As an IT manager, you often find yourselves concerned with resource allocation. By doing so, you exercise a big influence on the IT landscape. However, shaping teams is not an easy task. If you create the wrong team boundaries, you will end up with teams that have lots of dependencies and are more in meetings than they do actual development work. Ultimately, entanglement will slow down your organization in the long run.
Domain boundaries need to be respected and teams need to be structured accordingly. Teams working on a single domain can work in collaboration. Features that span multiple domains should be met with care, and require interfacing that does not require daily collaboration (like a message bus that decouples traffic between teams).
💡 Tip. You might have heard about Team Topologies. The book will give you practical instructions to shape your team while embracing DDD philosopy.
DDD creates a durable backbone improving maintainability
Domains — and an emphasis on the core domain — will put the heart of your business process into the heart of the software. Over the years, it became visible that this is a durable approach. Technology and data models change rapidly, but the core processes of your business rarely do with the same speed. In the past, we have trends that took other approaches, like database-centric software (leads to entanglement and does not scale), and API-driven practices (focuses too much on technical communication patterns with clients).
Centering on core domains is the most durable approach for engineering serious IT platforms in the long run. You will be able to accommodate ever-changing requirements better.
DDD implementation protects us from changes in technology
DDD can be used as an implementation style on the code level as well. We develop a core model in code, which concentrates valuable business logic. We then wrap our system interactions with the outside world as an onion layer around it. The benefit is that this keeps the fast-changing technology trends away from our core business rules. This allows us to more easily adopt new tools and trends (i.e. to be an attractive employer) while keeping our ‘valuables’ almost untouched.
💡 Reflection. Do you feel that your IT teams are pushed around by new technolgies? New technology can be a great enabler, but if it requires constant rewriting it will get costly fast.
DDD draws in the right engineering skills
This one needs nuance of course. I do believe that engineers who want to focus on engineering core domains have a high value. The effort it takes to produce something meaningful also correlates positively with decent retention. As long as they are well-treated of course.
Sometimes you need the ones who love doing shallow MVPs to prove an idea and run off to the next gig. Diversity matters 😉. The important thing is to recognize the difference. When you put a label on it, it allows you to manage and strategize.
Summary
So as a manager, there are plenty of good reasons to welcome domain-driven influences. We have read about six important DDD traits.
- Domains compartmentalize the IT landscape
- Domain language creates depth of understanding
- Domains offer a good foundation to structure your teams
- DDD creates a durable backbone improving maintainability
- DDD implementation protects us from changes in technology
- DDD draws in the right engineering skills
If you are in an IT leadership position, I am sure you will recognize some if not all as part of your daily decision-making. DDD will require an investment in time/resources and a learning path. My advice is to hire someone with experience and good people skills to prevent re-inventing too many wheels. Start small, and dream big.
Got interested, and want to explore DDD modeling techniques?
If you want to familiarise yourself with the different modeling techniques used in DDD, have a look at DDD models by example.
