How should business level objects be named?

Question

We are building a service-oriented system where we have separated the application into several layers:

1. SOAP web services (e.g., BuildingService.asmx)
2. Business logic layer (e.g., BuildingXXX)
3. Data Access layer (e.g, BuildingProvider)
4. Types (e.g., Building)

The SOAP web services simply instantiate an object of type BuildingXXX from the business logic layer in order to keep the implementation out of the SOAP web services. BuildingXXX then uses the BuildingProvider from the data access layer to return types defined in the data transfer object layer.

We have been unable to determine what we should call the objects in the business logic layer.

What is the "standard" naming convention for naming these business level entities?

Answer 1

I would naively go with BuildingRules (since this is what they are, right?) but then I don't actually know what are the conventions...

Answer 2

Personally, I would call your business logic layer services "BuildingService" then call the web services "BuildingWebService".

Or you could always go with the generic "BuildingManager" as well for the service layer..

Answer 3

i prefer prefixes instead of suffixes, so that the related layers sort together, e.g.

BizRuleBuilding,
BizRuleFacility,
...

Answer 4

Namespaces are your friends. How about BusinessLayer.Building, BusinessLayer.Facility? Use DataLayer.Building, DataLayer.Facility, etc. You get to call things what they are, yet they get to be different things.