0

I realize this sounds similar to How is layer between MVC controller and back-end called?, but that didn't quite clarify the situation I'm facing.

I have a backend system - for the sake of an example, let's say it's a company calendar system.

The system has some core domain logic implemented in a service layer. There are calendars, users, events, different user roles etc. Examples of responsibilities of the service layer are:

  • Ensure that a calendar always has at least one administrator.
  • Enforce rules that may be defined on a calendar (e.g. no events on weekends).
  • Notify other systems (directly or via pub-sub) when an event is created or updated.

Then there are controllers (mostly REST-ish). There are different sets of controllers as they cater to different ways of accessing the system - some are made to fit the needs of a Javascript SPA running on a browser, others may be intended to provide an API to other systems. And they do what controllers do:

  • Mapping HTTP requests to invocations in the service layer
  • Dictating the JSON representation of data in requests and responses.
  • Maybe some basic input validation as well.

But then there's also the logic that is not quite core logic in that it depends on which API is used to access the service, but it also doesn't belong in controllers. Most of it is authorization. Also, stuff like if a regular user deletes an event we should send a notification, but if the account admin does it, we don't.

I feel it would really make sense to separate this logic as a layer between the controller and service, so that the service layer can focus on manipulating objects without regard to who or what requested that. Not saying this makes sense everywhere, but I think it would fit this project well.

Now the issue I'm facing is mostly one of nomenclature. If I have EventsController and EventsService, every developer has a rough idea of what they do. But how do I name something in between? EventCommandsService? Is there any sort of convention or named pattern for this?

5
  • 1
    you choose names according to what the class/component does. Ask your EventCommandsService What the hell are you supposed to do in my system? If you can summarize it with a sentence of three words (or less), that's the best name possible. If the resulting name has Andor Or do review its responsibilities because it's likely having too many and that's why you have a hard time finding names.
    – Laiv
    Commented Apr 6, 2023 at 11:19
  • @Laiv I totally agree with that, in which case the class would be named EventCommandsProcessor. But sometimes there's more to naming - there's also conventions. For example, it's common to name classes "SomethingSomethingService", which is a terrible name as it doesn't tell you what the class does - and indeed in my experience these tend to be the classes that end up doing way too much - but we stick with it because of the wide convention that "if it ends in -Service, it contains business logic"
    – abl
    Commented Apr 6, 2023 at 12:47
  • -Service, it contains business logic Services never hold business logic. That's wrong and it has been wrong for many decades now. Forget these naming conventions because they have been perverted and perversion has been perpetuated for decades now. Ask your code (as I told you to do) and you won't be wrong. As you code and uncertainty fades, rename things. Poorly named classes, objects, vars and constants are also tech debt. If you reduce your language to 3 possible names (controller, services, repositories) so will you with your imagination and capacity to design more complex solutions.
    – Laiv
    Commented Apr 6, 2023 at 12:58
  • @Laiv There are designs in which services contain business logic. Are they poorly named? Yes. Poorly designed? Possibly. Have the conventions been perverted? Yes, but if they have been going on for decades, well, that's what makes them conventions. I didn't say I agree with the conventions. But they exist.
    – abl
    Commented Apr 6, 2023 at 13:39
  • @abl I also think business logic should go in the service layer. But would be wary about naming the classes SomethingService, it implies that it will do everything possible related to Somethings
    – Ewan
    Commented Apr 6, 2023 at 14:12

1 Answer 1

0

I would add additional endpoints for the variations on an action and put the logic there.

eg

event/delete
    logic.delete
    email.send

[Auth(Roles="Admin")]
event/deleteAsAdmin
    logic.delete

The reasoning is that the security is a cross cutting concern that lies as you say outside of your "business logic" even though the sending an email is a "business rule".

As well as handling route mapping, data de/serialisation etc the controller also handles the authentication mapping. Splitting the endpoint allows you to leverage this in a simple and understandable way.

If you had a similar but non security related issue, say 'only send the email on thursdays' Then I think adding an intermediate service layer would be the correct solution.

In regards to naming .net has a convention of appending "Controller" to controllers, but services can be layered several deep. try to think of better names in general. maybe you have an EventRepository?, Datalayer.EventCollectionManager? EventEmailer?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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