Look at the names of classes:

class BookService
class PaymentService
class UserService

Do you guess what these services are responsible for, what they do, what functions/methods they contain?

It is hard to guess. So

why do we name classes like xxxService?

Because it’s easy. We have a Book entity and without thinking we create a BookService and logic related to the Book concept goes into the BookService. Simple and easy. But

why we shouldn’t name classes like xxxService?

Because this is a quick way to a big mess in the application code. Each business function operates on multiple concepts/entities, so we need to involve a lot of services:

A mess. What should we do to make developers life easier?

‘Service’ suffix should be forbidden

If you do not allow the ‘Service’ suffix, programmers will start thinking about how to name classes correctly! This is a psychological trick 🙂 If they name it properly, I bet this class will be better suited to SRP (single responsibility principle).

Let’s look at an example. You have a certain business function: printing invoice documents. It’s easy to name the class PrintingService and put everything related to printing in it. But if you don’t allow the Service suffix, how can we name the class?

Printing or Printer – looks too short and too general

DocumentPrinter – better, but the name suggests that this class prints any document

You start thinking … about the name. Great. Ten seconds of thinking can make your design clearer and even save you a lot of time and frustration when looking for that particular class/implementation!

The best name in this particular case is:

InvoiceDocumentPrinter or PrintInvoiceDocument – like the businness function

Summary

Names have power, and we should use that power.