I recently started a new project where we are using the DDD principles to build our software. As most of my team members are new to DDD, I noticed some obvious mistakes. Here are some rules that can help you avoid the same mistakes…
Rule #1: Your domain should be modelled first
When you start a new project spend enough time on the domain before introducing a frontend and a database. Try to identify your bounded contexts, what are your entities? What can be a good aggregate? Which domain events are needed?
This allows you to really focus on the domain itself and explore it in depth. This is also a perfect time to introduce TDD(Test Driven Development) in your team.
Rule #2: Your domain should reflect your business logic not your database
If you start with Rule #1 you are already on the correct path. In too much cases I see that the domain is immediately setup in such a way that it works with the ORM tool the team has chosen. If the ORM needs getters and setters, they are added. If the ORM needs all properties to be public, it is changed.
Another thing I see is that people (especially if they are using a relational database) immediately start applying normalization techniques to let the domain better match with the database (and decrease the impedance mismatch). Unfortunately this leads to domain models that no longer reflect the domain and are coupled to your data storage mechanism.
Rule #3: Your domain should always be valid
Your domain should always represent a valid state. This means encapsulating validation inside your domain and ensuring that nobody can change the internal state. So no setters but only methods that encapsulate the behavior of your system.
This helps you to avoid a lot of extra guards and if checks spread around your code. And in the end this is where good object oriented design was all about…