In this chapter, you've seen a new way to factor business logic beyond encapsulating it in the Service layer—one that aligns the logic—implementing the validation changes, and interpretation of an object's data through a Domain class named accordingly. As with the Service layer, this approach makes such code easy to find for new and experienced developers working on the code base.

A Domain class combines the traditional Apex Trigger logic and custom Domain logic—such as the calculation of championship points for a contestant or the verification of compliance rules against the cars, drivers, and teams.

By utilizing Apex classes, the ability to start leveraging OOP practices emerges, using interfaces and factory methods to implement functional subsystems within the application to deliver not only implementation speed, consistency, and reuse, but also help support a common user experience. Domain classes can call between each other when required to encompass the behavior of related child components, such as drivers within a team.

Finally, when testing the Domain layer, keep in mind the best practice used for unit testing is to test as much of the code in isolation with varied use cases and data combinations despite the fact that other tests, such as those from the Service layer, and other callers will also exercise the code paths, though likely with less variation.

In the next chapter, we will complete the trio of patterns from Martin Fowler by taking a deeper look at the Selector pattern. This has been utilized a few times in this chapter when reading data from the various Custom Objects used in the application.