Andy in the Cloud

From BBC Basic to and beyond…

Apex Enterprise Patterns – Service Layer


In the previous blog post, SOC (Separation of Concerns) was discussed as a means to focus software architects into thinking about layering application logic. This next article in the series focuses on arguably the most important layer of them all, the Service layer. This is because, it is the entry point to the most important development investment and asset of all. Your applications business logic layer, it’s very heart!

Service Layer, “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.” Martin Fowler / Randy Stafford, EAA Patterns

Continue reading more at


10 thoughts on “Apex Enterprise Patterns – Service Layer

  1. Andy,

    Again, this is a great series of articles. Can’t wait for the Domain Model write up!

    Your examples of the “Data Mapper” and the concept of bulkification bring up a question for me. Martin Fowler talks about the following in his book “Patterns of Enterprise Application Architecture”:

    “A simple Data Mapper would just map a database table to an equivalent in-memory class on a field-to-field basis.”

    Your examples seem to suggest this pattern. What I mean is, the “Selector” classes will return standard Opportunity (and related) objects. The Opportunities class is a domain model “wrapper” around the standard Opportunity SObject (please correct me if I am wrong here). While the Opportunities are the “domain model” they are still only working with the standard SObjects.

    My question is around what your experience has been when the Domain objects differ considerably from their database SObject counterparts? In my experience, there have been times where I could have a single SObject that contains data from several different domain objects. In Java, I would take the mapper class and map the values from the resultset to the corresponding location in the object. This is not a big deal at all. When I run into this scenario in Apex, I find that this type of “complex transformation” could come at a cost. Specifically, if the resultset is large, transforming of the resultset into the equivalent domain objects can eat away at the “max number of lines executed in the request” governor limit.

    Have you run into similar issues? If so, do you have any advice about how to manage that the most efficient way?

    I appreciate the feedback.



  2. Hi John,

    Thanks for the feedback, much appreciated!

    The Domain Model article is starting draft this weekend you’ll be pleased to know.

    Your understanding of the Selector and Opportunities domain class construction is correct. These are examples of manifesting Domain classes around your applications physical data schema, and is most typical. However is not a hard and fast rule.

    It is perfectly fine to have a logical Domain model (structured or flatten into a single class) encapsulating any logic around data that is an aggregate or mix of information from the database (or even some other data source such as a web service).

    In this case a mapper class and methods on it would also encapsulate the various DB queries needed to retrieve this logical data into one. Such mapper methods would probably result in returning POJO type Apex classes or perhaps an interface that flattens a hidden set of SObject’s and/or AggregateResult objects for the consumers to access through. Using an interface will perhaps cut down on some of the transform cost, as your simply offering a facade over the underlying data your aggregating through it and not moving it around.

    You might also consider that you might not need a domain class, if its purely read information, the POJO/Interface returned by your mapper could be considered a kind of “light weight” Domain class in this case.

    This is certainly a good use case, I’ll look to weave an example of this into the upcoming article.



  3. Hi Andy, really enjoying reading your book and I have a question around Service class vs. Domain class and where code should go. Normally service layer calls domain layer which has more granularity. But in some situations, what if triggers require ‘less granular’ operations, for example creating other objects? I guess I am not understanding fully the rules for what code goes in the Service class and what goes in the Domain class.


    • Hi!

      Sorry for the delay in getting back to you, busy work week!

      If it is part of the behaviour of one object to create records in another, i’d say that belongs in its domain class of that object, so in the domain / trigger method in that class. If its a common behaviour you might consider putting it as a kind of static factory method on the related object domain class and delegating to that from others in such use cases. Similarly in update scenarios its also reasonable to delegate to another domain classes instance methods. Note in both these cases, if your using it i would create a UOW scope in the top level domain class method and pass through to the domain methods called.

      Generally if your finding your wanting to invoke code from the Domain layer you’ve already placed in the Service layer that implies its already being or available for use by something else as well. This can sometimes be kind of architecture smell. So when i see the domain layer calling a service layer it does give me pause for thought. I’m not a huge fan of making triggers do ‘task’ based logic, as the end user and platform API interactions are not hugely aware of the significance and it can lead to performance and governor issues. So be careful about what it is your doing and ask yourself if it is truly something that should be associated with a CRUD operation in your application or something else more task related like a VF page, custom button or scheduled job. Neither is wrong, but overused can result in an application that doesn’t respond well to being prodded from the numerous ways custom objects can be! 🙂

      • Thanks for the reply Andy – I understand the point about not having triggers do ‘task’ based logic as their impact can be unpredictable. But I guess that’s where good bulk tests come in?

        I think the idea of the static method on the domain object would work – but I think I need to work through some real examples to be fully clear.

        Thanks again – really appreciate you fitting this stuff in to your schedule.


  4. Hey Andy,

    I’ve been working on a project that is being built entirely on a service layer and custom rest resources. It’s a complete UI overhaul built on top of Salesforce data. I recently adopted your apex enterprise patterns to help add some maintainability to the code and reduce the number of decisions I have to make when adding code. It’s already paying dividends.

    I have a question about querying data records through the service layer. Your examples take for granted that the caller already knows about the SObject (e.g. from a standard controller on a VF Page), and will be handling updates to the record itself (e.g. the Save action). That makes perfect sense when you’re on the golden path, but I’m having to bushwhack on this project.

    If the caller doesn’t have it’s own way of getting and updating the SObject (i.e. custom rest resource consumer), how would you provide that ability to them? The pattern suggests this should all go through the service layer.

    To mimic how the standard VF page does it, I have various service methods that return lists of SObjects obtained from selectors, and a service method that updates a list of SObjects passed to it through an argument. It doesn’t quite feel right though. I don’t really want the caller to be aware of the entire SObject, and I want to restrict what fields they can update through the service layer.


    • Hi, glad your getting results from the pattern usage, really encouraging. In terms of your service layer and SOBJect’s yeah, your spot on it kinda feels odd to trust the callers set the correct fields or even for new callers, they should not be expected to worry about which SObject fields to set. In these cases if you have a specific set of fields. In this case i’d be inclined to define a DTO (Data Transfer Object) (also a Martin Fowler pattern), using an Apex inner class in your service class. You can then have private methods in your service class to convert to/from this to the SObject as needed. Then the contract your exposing on your service layer is nice and clean and clear. You can also express read only properties this way, so if you happen to use the Apex class in method responses and as an argument you can help clarity which properties need to be set in the argument instance more easily. Hope this helps, great question and do let me know how you get on, it would be good to see some experiences in a blog of someone migrating an existing code base to the patterns. Cheers!

  5. Hi Andy ,

    I have been thoroughly enjoying reading your book . Its been so enlightening to know how to design enterprise scale application. Though most of the concepts are easy to comprehend , I tend to get confused between what should go into Service layer vs Domain layer. It will be very helpful if you can have provide cheat sheet explaining this part. Some times it appears service layer is only used as an entry point ,whereas domain layer has most of the logic . Can you please elaborate bit more on why should methods like awardChampoinshipPoints and applyDiscounts exist in domain layer . We can always have these in respective service layers and let one service layer call other service layer . I think question should be more around , what is the criteria that says this can be called as behavior of an object and can be part of domain layer

    Thanks in advance !

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s