11

How do you name repository and service interfaces and their implementing classes?

For example I have a model with the name Question. What would you name the repository (interface and implementation) and the service (interface/implementation).

After reading these posts: Java Interfaces/Implementation naming convention and Interface naming in Java I reconsidered what I already had done :)

Community
  • 1
  • 1
LuckyLuke
  • 47,771
  • 85
  • 270
  • 434

2 Answers2

19

I think that there are roughly two approaches to naming in DDD:

1) Stereotype based. This is where you include class stereotype in its name. For example:

QuestionsRepository, TaxCalculatingService etc

2) Domain based. In this approach you use only domain language and omit any stereotypes in the class names. For example:

Questions (or AllQuestions), TaxCalculator etc.

Implementation classes would be named like SqlQuestions or InMemoryQuestions.

I tried both but I now prefer 2nd option as it seems to be more aligned with DDD mindset. It seems more readable and have a better signal-to-noise ratio. Following is a quote from a great article on repositories by Phil Calçado:

The concept of a Repository as a list of objects is not too hard to understand but it is very common for those classes to end up with methods that are not related to lists at all.

After coaching many teams in the adoption of a Ubiquitous Language and related patterns, I’ve found out that the best way to make people remember that Repositories are not DAO-like classes starts with how you name them.

Years ago Rodrigo Yoshima told me about his convention when naming Repositories. Instead of the more common naming style displayed below:

class OrderRepository {
   List<Order> getOrdersFor(Account a){...}
}

He promotes this:

class AllOrders {
   List<Order> belongingTo(Account a){...}
}

It looks like a small change but it helps a lot...

The whole article is well worth reading and bookmarking.

Dmitry
  • 17,078
  • 2
  • 44
  • 70
  • I know that this may be a minor detail but should the implementing class have the a suffix or prefix? SQLAllQuestions or AllQuestionsSQL? What do you prefer? – LuckyLuke Feb 22 '12 at 20:14
  • I personally would use SqlAllQuestions, but I don't see any reason for not using AllQuestionsSql, might be even better. As you saying it does not really matter because this name would only be used in a 'Composition Root' part of your application and you would not see it a lot (http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx) – Dmitry Feb 22 '12 at 20:22
  • One more thing. I read your link and it was great but what do you do when you have AllQuestions interface and you want to list all questions? AllQuestions.everything()? Are there any conventions or something when doing CRUD? – LuckyLuke Feb 22 '12 at 20:25
  • Questions.All() would be readable. CRUD is a whole other discussion, it is coming from _data_, not _domain_ world. It is better to think about lifecycle than about CRUD. Domain objects created with constructor or factory (C). You may also have a method Questions.Add(question) that would add object to a repository (internally repository would use hibernate for the implementation of this method). End of life is not always as simple as just Delete...(running out of space for comments) – Dmitry Feb 22 '12 at 20:41
  • "Questions" as repo name sounds good at first, but it leads to problems with plurals. Thats why QuestionRepository is better. You could replace the word repository with something more natural like QuestionGroup, but that not important IMHO. – Solubris Dec 28 '12 at 14:37
  • +1 for a great response. Unfortunately the link for the article is dead. :( Even without the link, still a great response – Jdahern Nov 23 '15 at 21:11
  • Dmitry, love your answer, thanks for the knowledge-share! How about even going further and say this has great potential to simplify the Repositories API by completely getting rid of methods for single value fetching. I.e. only return `Stream` and let the client decide whether they want to fetch the `.findFirst()` or `.findAny()` value. Example: `questions.withId(questionId).findFirst().ifPresent(...);` – Tob Feb 16 '22 at 09:08
2

I personally use FooService, FooServiceImpl, FooRepository and FooRepositoryImpl.

You might argue that the Impl suffix is noise, but

  • there's typically only one implementation, so there's no FirstFooService and SecondFooService
  • the concrete FooXxxImpl types are used nowhere in the code except in unit tests: dependencies are injected, and their type is the interface
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • I use `FooDao` instead of `FooRepository` because it's shorter to type :) – Paul Feb 22 '12 at 18:35
  • 1
    I don't see need for FooService interface since you only have one implementation. Purpose of interface is to model object/component which will likely have more implementations. Such as validationRule, some strategy pattern. I personally think that there are a lot of interface overuse. Also, fact that you have Impl sufix as your implementation tells me that your implementation is not anyhow specific. Implementation name should contain implementation specifics. For example, List, LinkedList, ArrayList. I know that this approach is common, but that doesn't mean it is good. – Vajda Oct 22 '15 at 17:57
  • I don't use interfaces anymore. Remember that this is an answer from 2012. frameworks and mocking frameworks have evolved since then. – JB Nizet Oct 22 '15 at 19:10
  • @Paul `DAO` and `Repository` are theoretically different. – wonsuc Apr 26 '22 at 03:58
  • @wonsuc The question was practical, not theoretical. It would be helpful if you explained the difference in your comment. – Paul Apr 27 '22 at 04:57
  • 1
    @Paul Both patterns are very similar but significantly different. `DAO` is an abstraction of data persistence, and `Repository` is an abstraction of a collection of objects. – wonsuc Apr 27 '22 at 05:44
  • Interfaces still play a role in the architecture game. In an Onion Architecture / Clean Architecture / Ports and Adapters you'd simply need them to make sure that dependencies point in the right direction. To avoid the humble `Impl` suffix, it is a good practise to express specifics about the implementation in the name, e.g. `PostgresOrderRepository`. – deamon Jul 07 '23 at 13:02