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.

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…

In respect to sitting above the API layer and turning DTO’s to/from Domain Object’s, I’d call them “Brokers”.

We had a separate namespace called BusinessLayer, often abbreviated BL.

At their most general, they are “data processors.” In common parlance, they’re often called “algorithms,” although some folks insist that that is reserved for programs with trivial control flow. For disambiguation and comparison:

• A service is an API surface and a contract promising that the surface has certain behaviors; data processing may be part of how the API is implemented. In practice, a service is e.g. an HTTPS endpoint and an OpenAPI specification.
• A capability is a copyable token which simultaneously authorizes its holder to perform an action and designates the holder as having the authority to perform that action. This won’t be part of your normal curriculum and training; see this post for an introduction, or this story for motivation.
• A controller is a modulator for a (distributed) system. Typically a controller is anything which is actuated by a control loop, although sometimes a controller can sit outside of the system. Common examples include MVC patterns, k8s components, and video-game controllers.

Services or uscases

Business services

Daemons?