So far, we have only discussed Separation of Concerns between the Apex code invoked from an execution context (Apex Controller, Scheduler, Batch Apex, and so on) and reusable application business logic code placed in the Service classes. However, there are further levels of granularity and patterns that help focus and encapsulate application logic further, known as Enterprise Application Architecture patterns.
The general definitions of the patterns used in the next three chapters of this book are not inherently new, but are a new implementation for this platform. They have been and continue to be incredibly popular on other platforms. The original author of these patterns is Martin Fowler, who describes the other patterns in his book, Patterns of En terprise Application Architecture (http://www.martinfowler.com/books/eaa.html)
This book takes some of the patterns in Martin Fowler's book and applies them to the platform while also taking the opportunity to bake in a few best practices on the Force.com platform. The next section is a short summary of those we will be taking a closer look at.
The following is Martin Fowler's definition of the Service layer (http://martinfowler.com/eaaCatalog/serviceLayer.html):
"Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation."
You had a little preview of this pattern in action within this chapter. You can see that for the business application logic, it forms an initial entry point, encapsulating operations and tasks the end users perform.
Its methods and behavior are designed such that it is agnostic of the caller, making it adaptable to multiple execution contexts easily, as shown in the earlier examples. It also has a role to play in your applications API strategy.
The following is Martin Fowler's definition of the Domain layer (http://martinfowler.com/eaaCatalog/domainModel.html):
"An object model of the domain that incorporates both behavior and data. At its worst, business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with."
If you think of the Service layer as the band conductor, the Apex classes that make up the Domain layer are the instruments it conducts, each with its own role and responsibility in making the music!
The Domain layer in a Force.com context helps group and encapsulate logic specific to each physical Custom Object in the application. Also, while utilizing object-oriented concepts such as interfaces and inheritance to apply common behavioral aspects between your Custom Objects in your application, such as security, it is responsible for applying validations and processing historically done in the Apex Triggers code directly. Note that the Service layer can leverage these classes to form high-level business application logic that spans multiple objects and thus can access and reuse domain object-specific logic.
The following is Martin Fowler's definition of the Data Mapper layer (http://martinfowler.com/eaaCatalog/dataMapper.html):
"A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself."
Making effective use of database queries to fetch data is as important on Force.com as any other platform. For complex object models, having SOQL do some of the heavy lifting can lead to some fairly sophisticated queries. Encapsulating how data from the database is mapped into memory is the role of the Data Mapper layer.
In Martin Fowler's world, this usually involves mapping database result set records returned into Java classes (known as Plain Old Java Objects (POJO) or Data Transformation Objects (DTO)). However, Apex provides us with these data structures for each of our custom objects in the form of SObject. Thus, the role of this pattern is slightly different, as the SOQL query itself explicitly selects SObject representing the data. Hence, this pattern has been renamed to reflect its key responsibility more accurately.
There exists an Apex class library used to support these patterns, which is also used in this book. The Apex Commons library is from an open source project started by FinancialForce.com and launched to the community at the Dreamforce 2012 event.
Since then, the patterns have been adopted by other developers on the platform and have been extended with additional features such as Fieldsets and Security. We will be using this library in the next three chapters as we explore the enterprise patterns they support in more detail. The GitHub repository can be found at https://github.com/financialforcedev/fflib-apex-common.