As in the previous chapter, this section provides some general design and best practice guidelines around designing a Domain layer class for a given object. Note that some of these conventions are shared by the Service layer, as it also calls the Domain layer because conventions such as bulkification apply to the logic written here as well.
The key principle of the Domain layer pattern is to lay out the code in such a way that it maps to the business domain of the application. In a Force.com application, this is typically supported by the Custom Objects. As such, it's important to clearly indicate which Domain layer class relates to which Standard or Custom Object:
Avoid acronyms: As per the previous chapter, try to avoid these unless it makes your class names unworkably long.
Class names: Use the plural name of your Custom Object for the name of your Domain class. This sets the tone for the scope of the record that the class deals with as...
