Are You Making These 10 DDD Mistakes?

Making mistakes is part of programming. Spotting them early can save you time. I’ve started to notice a common set of ‘DDD Mistakes’ which many of us seem to make. And yes, I’ve made them all at some point in my career. This is by no means the definitive list – I’m sure there are more.

If you find this guide helpful, please share it with others. There is an embed code at the bottom for re-publishing on your blog.

Are You Making These 10 DDD Mistakes

Download this infographic.

Embed Our Infographic On Your Site!


I'm a professional software engineer of near on 15 years. Lucky enough to work for a small but rapidly growing company in London called Redington. They have given me the technical freedom to learn some cutting edge technologies like CQRS and Event Sourcing. Now I'm sharing what I learn here.

7 thoughts on “Are You Making These 10 DDD Mistakes?

  1. Nice post, made most of them myself (and more). One point of interest, in the blue book Eric Evans says that “it is worth accepting model limitations in order to keep the [database] mapping very simple” (page 159). That’s something that doesn’t really seem to be a common point of view these days, and is also in contradiction with point #1. I personally agree with you, since I’ve seen a couple of projects gone bad because of database influences in the domain model. What are your thoughts on that?

    • Daniel says:

      Good question. My take on it is we (developers in general) tend to lean toward a database first mindset. If attempting to follow a DDD approach this can become a problem. I’ve found that making a point of avoiding it at the start can help the design. That’s not too say you don’t end up ‘accepting model limitations’ but that you don’t start with them.

      • freekpaans says:

        I like that, a database-first mindset is indeed common and problematic in this context. However, I’ve also seen projects go through tremendous effort to avoid coupling to the database at all, resulting in a lot of complexity that ended up drawing attention away from the domain. It’s a delicate balance, I guess.

  2. […] Are You Making These 10 DDD Mistakes? (Daniel Whittaker) […]

    • nice write up, i am learning DDD at the moment so am very aware of some of these mistakes 😉

      Can you elaborate on security in the domain? are you meaning what adminstrator can do what in terms of access level?

      • Daniel says:

        The rule of thumb to follow is to leave security out of the domain. So, when modeling how to ship a parcel to its destination the application security should be done before it gets to the domain. The responsibility of the domain code in that case to work out the cheapest/fastest/safest route. However, if the result was contingent on the access level of the issuer, then it makes sense to include it. I hope that makes it clear.

Comments are closed.