In this chapter, we have taken an in-depth look at how the platform executes the Apex code and the different contexts from which it does so. We have also taken time to understand how key concepts like state and security are managed, in addition to highlighting some Apex governors and their respective scopes.
This has allowed us to observe some common needs from which we have distilled into a Separation of Concerns that we can start to apply as guidelines into layers in our business application code, making the Apex logic more reusable and accessible from different contexts as your application functionality and indeed the platform itself evolves.
As we progress further into practicing Separation of Concerns, the Domain, Service, and Selector layers' patterns will become a further layer of separation within our application business logic. We will continue to define the naming and coding guidelines as we progress through the next three chapters so that it becomes easier to maintain a good Separation of Concerns for the existing developers and those just starting to work on the code base.
Tip
If you have an existing code base and are wondering where to start with refactoring its code up into the layers described in this chapter, my advice is to concentrate initially on forming your Service layer contract and refactoring as much true business logic code into it as possible. Make your execution context classes, such as controllers and Batch Apex classes (but not triggers initially), as thin as possible, leaving them to focus solely on their responsibilities such as error handling. This will get some of your true business application logic at least contained below the Service layer, even if it might not be factored precisely how you would want it had you have written it from scratch. After this, you can focus on expanding this out to refactoring the Trigger logic into Domain, then the Query logic into separate Selector classes, perhaps incrementally, as you revise the areas of the application for enhancements.