How should business-level objects be named?

Question

We create a service-oriented system in which we divided the application into several layers:

• SOAP Web Services (e.g. BuildingService.asmx)
• Business Logic Level (e.g. BuildingXXX)
• Data Access Level (e.g. BuildingProvider)
• Types (e.g. Building)

SOAP Web Services simply instantiates an object of type BuildingXXX at the business logic level to preserve the implementation from SOAP Web Services. BuildingXXX then uses the BuildingProvider from the data access layer to return the types defined at the data transfer object level.

We could not determine what we should call objects at the level of business logic.

What is the “standard” naming convention for these business-level entities?

Answer 1

Personally, I would call your business logic services “BuildingService” and then call the BuildingWebService web services.

Or you can always go with a common "BuildingManager" as well as a service level.

Answer 2

Namespaces are your friends. What about BusinessLayer.Building, BusinessLayer.Facility? Use DataLayer.Building, DataLayer.Facility etc. You can call things what they are, but they become different.

Answer 3

BuildingRules ( , , ?), , ...

Answer 4

I prefer prefixes over suffixes so that related layers are sorted together, for example.

BizRuleBuilding,
BizRuleFacility,
...