Stealing from "Domain Driven Design", I think calling them "domain objects" is appropriate.
this post was submitted on 30 May 2024
1 points (100.0% liked)
Experienced Devs
3928 readers
1 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:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
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.
i call then the "domain".
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 had a separate namespace called BusinessLayer, often abbreviated BL.
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
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…