Introducing the Service layer pattern

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 contexts caller. This might be 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.

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 (that is, whether the next developer will 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 toward any particular caller.

Table of Contents for Introducing the Service layer pattern

Create new playlist

Sign In

Sign Up

Table of Contents for
Introducing the Service layer pattern