If your application were considered a living organism, the Service layer would be its beating heart. Regardless of how the environment and the things that interact with it change over time, it must remain strong and able to adapt. In this chapter, we begin our journey with the three coding patterns: Service, Domain, and Selector, which were introduced in Chapter 4, Apex Execution and Separation of Concerns.
In this chapter, we will review the pattern as set out by Martin Fowler and then review how it has been applied on the Force.com platform in Apex, describing design guidelines born from the Separation of Concerns we defined in the previous chapter.
One concern of this layer is interacting with the database; a later chapter will cover querying this in more detail. This chapter will focus on updating the database and introducing a new pattern, Unit Of Work, which helps make your code more streamlined and bulkified.
At the end of this chapter, we will extend the FormulaForce application to provide a means to calculate driver championship points and issue a newsletter. The code developed in the Service layer will be invoked from Custom buttons and the Apex Scheduler. Later chapters will also cover further uses of the Service layer.
The following aspects of the Service layer will be covered in this chapter:
- Introducing the Service layer pattern
- Implementation design guidelines
- Handling DML with the Unit Of Work
- Services calling services
- Contract Driven Development
- Testing the services
- Calling the services
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."
The use of the word boundary in Martin's definition is interesting, as this literally represents the point of separation or boundary between the concerns of the application's business logic in the Service layer and execution context or caller, be that a Visualforce or Lightning Component Controller class or a Batch Apex class, as illustrated in the UML diagrams shown in the previous chapter.
The following illustration shows just some of the types of callers that an Apex Service layer is designed to support. By following the design guidelines given in the next diagram, you can ensure that your Service layer code can be called from any one of these features and others in the future:
This book will illustrate the use of the Service layer in a number of these areas.
The reference to boundaries in Martin's definition is also an important point with respect to the encapsulation of the application's true business logic. You must be diligent about this encapsulation since the Service layer cannot coordinate the behavior of the application without it. The patterns in this book help to promote better thinking about encapsulation. However, there are no ways to express dependencies between Apex code in the way other languages such as Java might use the package and protected keywords, for example. As such, it is down to us to make sure that there is a solid awareness and desire to honor them.
Tip
Code reviews are an integral part of any development process. One easy indicator that your application business logic may be leaking outside of your service layer is the increasing amount of code in the calling classes, such as Visualforce or Lightning Component Controllers or Batch Apex classes. Remember that these classes have their own concerns as well, such as handling and reporting errors and presenting information that the Service layer or your custom objects need. Though generally, if the code looks to be doing more than this, it could be a sign that there is some code that should have been factored into a Service method. The hard part is often failing a code review based on this observation, particularly if the author claims there is no current reuse case. While that may be true, ignoring it in the beginning and letting it remain increases technical debt, limits reuse (will the next developer have time to refactor?), and increases the risk of inconsistent behavior across your application.
Finally, keep in mind that the information exchanged with the Service layer is not necessarily targeted to a specific use case or caller requirement. It is the responsibility of the calling code, such as a Visualforce or Lightning Component Controller or even code written by a subscriber org developer, to translate between the chosen client user interface and the Service layer interface.
In Chapter 10, Providing Integration and Extensibility, we will also explore exposing your Service layer as an API for external consumption. For these reasons, the Service layer has to be agnostic or unbiased towards any particular caller.