0

I have a service that looks like:

class UsersService {
  create() {...}
  update() {...}
  
  getRandomUsername() {...}
  isUserOld() {...}
}

Should methods "getRandomUsername" and "isUserOld" be placed inside service? Or they should be moved to some separate "UsersHelper" class and be called from there?

eugenedrvnk
  • 408
  • 1
  • 5
  • 10

1 Answers1

0

Service layer ind DDD (Domain Driven Design) architecture is supposed to be responsible for domain operations AND Business Logic. If you consider operations "getRandomUsername" and "isUserOld" Business Logic then it's fine to have them in the UserService service. Especially if they really do operations on/with the "User" entity.

Usually people try to avoid creating classes like Helpers or Managers, because what happens is that eventually everyone in your team will be putting all the "general" code inside of one GodHelper class. If you want to create several helper classes for every entity in your domain then you basically recreate a service layer.

SergeyAn
  • 754
  • 6
  • 9
  • I suppose, "getRandomUsername" and "isUserOld" are not business logic, they are just like helper methods to be used inside other "UsersService" methods (that already handle business logic) and by other services. In that case, these methods still should stay inside UsersService? Btw, in my app I create "SessionManager" class to manage session keys (like "sessionManager.setUser/getUser and so on). Is it also bad practice? – eugenedrvnk Dec 21 '22 at 14:46
  • I would leave them in the UserService. You need to ask yourself a question, can your application live without these methods? What part of it will stop working correctly if you remove one of them or both? To me, "isUserOld" looks like part of business logic. "SessionManager" looks like a service to me, but again ask yourself a question do you really need it? Maybe you can use something that is provided, say, by default? For example check classes related to http context. – SergeyAn Dec 21 '22 at 20:06