We know that domain-driven design (DDD) can be tricky to implement. We have helped many clients along the way, getting them out of these pitfalls and steering them clear of other pitfalls. This is why I created our DDD Don’ts webinar on this topic - because inevitably, you’ll try to do some things in DDD with what you know and without realizing that it might be a bumpy road.
So let’s talk about some of the pitfalls that were covered.
The Golden Hammer of DDD
Too often, people get excited about learning a new concept or technology and want to apply it everywhere. They see the new thing as a golden hammer. I get the excitement, but at the same time, DDD is not fit for every case.
Some cases where DDD doesn’t make sense include:
- CRUD-Heavy applications
- Small, short-lived projects
- SaaS products without complex business logic
These are some cases where DDD makes sense:
- When there is complex business logic within a domain
- May only need to be used on some domains, not all domains
- When there are high demands for scalability and extensibility
- Where developers can access the domain experts
Remember: DDD is a tool, not a rule.
Blurred Lines of Boundaries
Another pitfall we run into is identifying who owns the data. A common scenario I’ve seen is when it comes to the concept of a “customer”.
- Marketing sees customers as potential leads.
- Sales sees customers as current customers.
- Support sees customers as people who they have to support, especially when customers put in support tickets.
If you don’t have the conversations to identify a clear owner of the data, you might see someone go with a shared customer database. Then, Support changes could impact Sales and Marketing. There could be cascading changes. It could look messy like this:
However, by having the conversations and clearly identifying who owns what data, you could see the flow of customer links more like in this flow, where Support and Marketing can refer to the customer by ID, and Sales ultimately owns the Customer data.
Anemic Domain Models
Often times, we see classes in the business logic layer that are more like property bags or persistence models. These are known as anemic models. The business logic is handled by a service, even if it’s only one entity that is being handled. This is a maintenance nightmare and recipe for disaster.
When developing code with a DDD mindset, you want to keep your domain logic with your entities where it makes sense. Domain services have a place, but if there’s just one aggregate involved, domain services are not what you need.
Rich domain models have properties as well as business logic. They are easier to test, as you don’t need a service layer for testing. They are easier to maintain since the domain logic stays within its relevant domain objects. This is an example of a rich domain model:
Lone Wolf Syndrome
Sometimes, developers will make assumptions of the requirements and run with those requirements. They will write code with their assumed requirements in mind. They’ll write tests to ensure that the assumed requirements are met. When they show the code to their stakeholders, the stakeholders are frustrated and not happy with the delivered product. Why? Because of the assumed requirements.
As developers, we need to ensure that our requirements are the actual requirements. This means that we need to talk with the stakeholders and domain experts to ensure that we have the right understanding. Even if you’ve worked on a similar project in a similar industry, assuming that the rules from one apply to another is foolish. Make use of the domain experts and their knowledge. Our job is to solve problems, and we want to solve the right problems with the right understanding. We don’t want to waste precious coding time by writing code for an assumed requirement, only to learn that we are way off base.
In a domain-driven design environment, the developers have access to the domain experts. This access is crucial. While there may normally be silos and office politics to cause issues in many places, those roadblocks and hiccups aren’t as common in the domain-driven design realm. Communication and collaboration are keys to the success of DDD implementations.
Conclusion
These are just a few of the many pitfalls we cover in our DDD Don’ts webinar. If you are struggling with getting domain-driven design implemented in your environment, consider reaching out to us for help!
Additional Resources
These are some additional resources for DDD: