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.
- 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
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?