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?

  • 1
    This is a tough one, by "technical terms" I think what you're referring to is commonly called a "Pure Fabrication" in DDD terms - "A Pure Fabrication is a class that does not represent a concept in the problem domain".
    – MattDavey
    Commented Feb 14, 2013 at 13:46
  • 2
    Just because you are implementing a certain design pattern doesn't mean that you have to name everything according to how it's named in the Design Patterns book.
    – Philipp
    Commented Feb 14, 2013 at 15:15

2 Answers 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

  1. Find a satisfying synonymous with the domain expert
  2. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.