Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 Feb 14 '13 at 13:46
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 Feb 14 '13 at 15:15
up vote 3 down vote accepted

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".

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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