I have been reading DDD Quickly and wondered about how to avoid naming clashes with technical terms and domain terms. For example, if I commonly used the repository pattern (with classes such as AddressRepository), but a customer also has something called a repository in their domain. How would I best avoid confusing the two?
2
I would say that in the spirit of DDD’s Ubiquitous Language, the Domain definition of the clashing term should take precedence over the programming infrastructure term.
In your case, if there is already a Domain definition for “Repository”, then you should choose another name for your AddressRepository that doesn’t clash, even though the class is implementing the DDD repository mechanism. After all, you don’t have to append “Repository” to the end of the class name, it’s just a convenience to you, the programmer. I would probably just call it “Addresses”.
In most of cases, when a clash exists you can find with the domain expert a perfect synonymous that removes the ambiguity.
When no synonymous exist, the problem is not about the code base since the compiler knows about namespaces (and btw no repository should be in the same module of the domain), but about developers’ cognitive load.
Indeed, when new developers join the project, they will have to learn about the “different” meaning of “that one term” and they will take some time to become able to understand from the context if you are talking about the technical concept or the domain’s one (and believe me, this is both annoying and expensive).
Thus, I suggest to
- Find a satisfying synonymous with the domain expert
- If (and only if) no synonymous exist
- use the term from the ubiquitous language as it is (Repository, in your case) for the domain concept
- use the naming convention that developers already adopt for the technical concept (AddressRepository here) or you will have to spend time to explain the exception a lot of times!
This might look too pragmatic, but works well.