Documentation

Some annoying things that I ran into when implementing DDD that weren't obvious right away.

Database id's

A domain does not know about the existence of a database and entity creation belongs inside the domain. That raises the question how to create your id's. You could leave the id null and only assign it when saving to the database, but that leaves the domain in an invalid state for a short time. So then how do we assign id's to a new entity? The answer is to use unique id generators that don't rely on database calls, such as the HiLo algorithm.

Repositories and their interface

One of the rules of the hexagonal architecture is that dependencies point inside, meaning that you are allowed to call classes in layers closer to the center (or your own layer), but not the other way around. This causes a problem with repositories, as they are in the outer most layer, but need to be called from the inside (the application layer).

Some people 'solve' this by saying that the interface of the repository does not reside in the outermost layer, so now application services (or even domain services) can call repositories, but that feels like cheating to me. I 'solved' this myself by admitting the world isn't perfect and we'll make do with this one exception, but if you happen to know a good solution here (or have a good argument why the interface really does live on a different level than it's implementation) then please tell me :).

Uniqueness validation

Some properties of a domain model (like usernames) are unique, which means the domain model should check for their uniqueness. We can do that by querying the database inside the domain, which breaks its isolation, or we can do that check outside the domain, which breaks the single responsibility principle. I think doing this check outside the domain is the lesser of the two evils.
See also this blogpost on domain model purity vs completeness.