How can you identify a Domain-Driven Design project?
Determining complexity isn't all that complex...there's a trick!
I’ve been working in Domain-Driven Design projects since 2015 and have become a strong advocate for cloud-based application modernization through modeling and related processes (Event Storming).
To refresh everyone’s memory, DDD was the culmination of architecture insights by Eric Evans, who published the book, “Domain-Driven Design: Tackling Complexity in the Heart of Software” (on Amazon), also known as, “the blue book.”
Another book, published by Vaughn Vernon, is titled “Implementing Domain-Driven Design,” (on Amazon), and is known as, “the red book.”
DDD essentially promotes the idea that enterprise software systems in medium to large companies can become very complex and that by using DDD principals, we can engineer more maintainable and malleable software that mirrors how the business views its internal processes. If you can read the model, you can read the code. Adding a new feature shouldn’t be decided on the complexity of the current software implementation.
But one of the blockers I’ve seen with a lot of companies in this predicament is how do you know that DDD will help? Where do you start? How can you be sure you’ve identified an application or series of applications that would benefit from DDD modeling and implementation (or re-implementation).
One way to accomplish this is to run an Event Storming session. Event Storming is business process modeling session with a twist. It all happens in a short period of time, with all of the key players including users, product owners, developers, testers, and anyone else that has some role in the usage, design, and implementation of the system(s). There are many benefits of running an Event Storming session, but an important result is understanding some of the boundaries within your systems. Boundaries are a key component in reducing complexity.
I have come to believe there is a tried and true method of identifying an overly complex system that would greatly benefit from Domain-Driven Design modeling and re-implementation.
When a company has a relational database that hosts the operational data for two or more systems/products. In fact, the more systems involved with a single relational database, the more likely complexity is at the heart of its maintenance and ability to add new features without great cost and risk of destabilizing the existing functionality.
This is actually very common. In the 2000’s, there was a concerted push by software architects to build company-wide object models and relate them to entity-relationship diagrams eventually hosted in am RDBMS (SQL Server or Oracle were the likely products involved).
This eventually produced Object-Relation Mappers to help developers serialize/deserialize data between the database and their object tree. This led to dependency injection, and now we have a group of applications that are massively opaque and very difficult to maintain and worse, very time-consuming to do knowledge transfer. I can’t tell you how many times, as a consultant, I landed at a client where developer churn was high except for the one chief architect that had originally designed the systems and was too valuable to let go. Many times these architects were highly paid and catered to because the business simply couldn’t function without them.
The complexity was actually supported to enhance this person’s job security and high income.
I won’t go scorched earth because there is tremendous value in using relational databases in any capacity. The speed of development has to be a factor. But I will say that if complexity will be a future factor (multiple systems connected by internal or external business processes), then relational databases are an operational anti-pattern.
I was one of those architects that built systems from the ERD up, so I know there’s a legacy here none of us can get away from. But we’re smarter now and we have better tools and processes to build software.
Domain-Driven Design and Event Storming are two of those tools. We can identify bound contexts, root aggregates, ubiquitous language, value objects, read models and from all of that build better, maintainable, and updateable systems.
If you have an operational relational database that hosts multiple systems, there’s a very strong case to be made that DDD can help improve those systems and the business that operates them.