submitted 3 weeks ago by vvv to c/experienced_devs

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?

top 18 comments
sorted by: hot top controversial new old
[-] BehindTheBarrier 6 points 3 weeks ago* (last edited 3 weeks ago)

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.

[-] vvv 1 points 3 weeks ago

Thanks for that, I think Engines is winning in my mind so far!

[-] [email protected] 5 points 3 weeks ago* (last edited 3 weeks ago)

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…

[-] [email protected] 4 points 3 weeks ago

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

[-] towerful 2 points 3 weeks ago

"broker" as a service-between-services is a great name

[-] tatterdemalion 3 points 3 weeks ago

Stealing from "Domain Driven Design", I think calling them "domain objects" is appropriate.

[-] vvv 1 points 2 weeks ago

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.

[-] tatterdemalion 1 points 2 weeks ago

Perhaps "domain modules" if you want to be more agnostic about the actual shape of the code.

[-] TomasEkeli 2 points 3 weeks ago

i call then the "domain".

[-] [email protected] 2 points 3 weeks ago

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

[-] [email protected] 1 points 3 weeks ago* (last edited 3 weeks ago)

I would call them “agents” at a class layer and encapsulate the logic specific to each domain in its own class. Completely arbitrary but in my mind: adapters - call other web services

dao - database calls

agent - responsible for stitching the pieces all together and doing the actual business logic.

Example: OpenWeatherAdapter - call the OpenWeather API. No business logic. H2SelectDao - get user preferences from an internal database. No business logic.

WeatherAgent(openWeatherAdapter, h2SelectDao) - All the business logic.

Note: this is in context of a API service like a middleware.

[-] [email protected] 1 points 3 weeks ago
[-] Ismay 1 points 3 weeks ago

Services or uscases

[-] drjkl 1 points 3 weeks ago
[-] vvv 4 points 3 weeks ago

(often abbreviated BS)

[-] Corbin 1 points 3 weeks ago

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.
[-] [email protected] 1 points 3 weeks ago

We call the things that, "sit in the middle," Middleware.

[-] RonSijm 1 points 3 weeks ago* (last edited 3 weeks ago)

I'm not completely sure which classes you're talking about - but it sounds like the Business Process Layer

I would call them “services” but I’m looking for a less overloaded term. Maybe capabilities? Controllers?

"Controllers" (in dotnet at least) is usually reserved for the class that initially intakes the http request after middleware (auth, modelbinding etc)

It's probably easier with a concrete example, so lets say the action is "Create User"

It depends on the rest of your architecture, but I usually start with a UserController - that takes all user related requests.

To make sure the Controller doesn't get super big with logic, it sends it though mediatr to a CreateUserCommandHandler

But it's a big vague which parts you're asking about..

"there is a class of … classes/modules that does the needful.".

Everything else you've described

"API resources, queue workers, repositories, clients" and serializers

Is "cross-cutting", "Data Access Layer", and "Service Agent Layer" maybe a bit "Anti-corruption Layer" - but there's a lot of other things in between that "do the needful"

this post was submitted on 30 May 2024
15 points (100.0% liked)

Experienced Devs

3843 readers
2 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 1 year ago