My co-workers tend to think that it is better to limit non-domain type suffixes to a small fixed set of OOP-pattern inspired words, e.g.:

  • *Service
  • *Repository
  • *Factory
  • *Manager
  • *Provider

I believe there is no reason to not extend that set with more names, e.g. (some "translation" to the previous vocabulary is given in brackets):

  • *Distributor (=> *DistributionManager or *SendingService)
  • *Generator
  • *Browser (=> *ReadonlyRepositoryService)
  • *Processor
  • *Manipulator (=> *StateMachineManager)
  • *Enricher (=> *EnrichmentService)

(*) denotes some domain word, e.g. "Order", "Student", "Item" etc.

The domain is probably not complex enough to use specialized approaches such as DDD which could drive the naming.

closed as primarily opinion-based by durron597, gnat, user40980, Kilian Foth, user22815 Aug 3 '15 at 14:09

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Sorry, what's DDD? – zuiqo Aug 18 '14 at 10:00

You can have any vocabulary you want, as long as everyone in team understands and agrees on what it means.

The reason why design patterns exist is that their names are (usually) widely known and even someone else outside your team knows what you mean when you say "This is a Builder". The problem I see with your proposal is just that. I have no idea what any of those mean. If you can agree with your team that you are using some pattern and agree on what that pattern is, then giving it some fitting name is obvious final step.

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