Somewhere between API resources, queue workers, repositories, clients and serializers there is a class of … classes/modules that does the needful. Gun-to-my-head, I would call them “services” but I’m looking for a less overloaded term. Maybe capabilities? Controllers? Pick a term from the business domain? What do you call them?
i call then the “domain”.
In respect to sitting above the API layer and turning DTO’s to/from Domain Object’s, I’d call them “Brokers”.
“broker” as a service-between-services is a great name
Stealing from “Domain Driven Design”, I think calling them “domain objects” is appropriate.
that’s a good call actually. I got pretty hung up on domain objects being mostly data classes, but one approach is to have them perform business logic themselves.
It’s not that universal, but we have named a few things “Engines”, for example Balancing Engine. We also use services, but they are actually independent programs that performs jobs. Engine are used in other places, such as the ViewModels, or in the services.
We put them in the DomainModel project which most things reference though. That’s were most basic functionality and shared resources end up if they are used across Client/Service/Backend projects. So Domain / DomainModel might be a thing to use as well, if you want a specific namespace for that kind of use.
Business services
(often abbreviated BS)
We call that business logic layer “services” at work too, for lack of a better word, but I’ll be watching over this thread for better ideas…
We had a separate namespace called BusinessLayer, often abbreviated BL.
