Questions about API parsing methods in Service Layer + Passing down newly instantiated SObjects to Domain layer

[ghost]

Hi,

I am a bit confused about this code example from chapter.5 of @afawcett his book. Why is this method in the Service layer and how is it reusable in its current form? I can not think of any other caller of this method, then a (single) resource class, cause it is written for a very specific use case in my view. In addition I was thinking, shouldn't the code in that method be partitioned into smaller separate methods to improve code reusability? Last question, I also noticed he is creating SObjects and assigning field values directly in the Service layer. In some blogs, like this one https://quirkyapex.com/2016/09/03/fflib-service-layer/ I read "One thing we shouldn’t be doing is performing any direct manipulation of sObjects here. ". Is meant with not manipulating SObjects also assignment of values of newly created SObjects (e.g. setting a relationship field on any of the objects in that method by some property received in the payload)? Cause in an alternative implementation he could pass down the newly instantiated record to the corresponding Domain layer and using a bunch of setValue() methods to assign the appropriate field values. However, I am not sure if that is really the way to go.

I am currently working on a similar use case and have created these setter methods in the Domain layer, but I am questioning if that doesn't create too much overhead and/or if it is really useful. For instance, going this route I would need to mock every setter method in my unit tests.

public IService handleSoftCancellation(fflib_ISObjectUnitOfWork unitOfWork, CancelSubscriptionRequest request) { List<Subscription__c> subscriptionRecords = SubscriptionSelector.newInstance().getActiveSubscriptionsByCustomerIds(new Set<String>{request.ResourceId}); List<Account> accountRecords = AccountSelector.newInstance().getCancellationDataByCustomerIds(new Set<String>{request.ResourceId}); if (!subscriptionRecords.isEmpty()) { getSubscriptionDomain(subscriptionRecords) .setAutoRenewField(false); unitOfWork.registerDirty(subscriptionRecords); } if (!accountRecords.isEmpty()) { getAccountDomain(accountRecords) .setSoftCancelledField(true) .setCancelReasonField(request.CancelReasons) .setCancelReasonCommentField(request.Comment); unitOfWork.registerDirty(accountRecords); } return this; }

Cheers,
Jens

[ImJohnMDaniel]

G'day Jens

Why is this method in the Service layer and how is it reusable in its current form? I can not think of any other caller of this method, then a (single) resource class, cause it is written for a very specific use case in my view.

• This method involves some level of business logic and/or DML. With those two criteria alone, this functionality would belong in the Service layer. In general, you want to avoid either of these two in controllers, REST APIs, webservices, invocable methods, or any other "service tier client".
• While the service method in this instance may only be called from one place, it is still reusable because there is always a chance that another service tier client could need to call it. A simple refactoring or overloading of the importSeasons method is all that would be needed in order to take advantage of this method.

In addition I was thinking, shouldn't the code in that method be partitioned into smaller separate methods to improve code reusability?

• fair comment

Your questions about "altering SObjects in the service method" is certainly a fair point. Using the domain class to set the defaults is definitely going to happen, but through the trigger context. So, it could be viewed as a bit of gray area in this case. In my opinion, both approaches are fine. Others may disagree and that is fine.

In your service method example, I agree that having all of the setters on the domain class will incur more overhead than is probably practical or you would want. In the case of the setCancelReasonCommentField(request.Comment); method, it kind of implies that the service class is responsible for "which field should be used off of the request object." Shouldn't that be the responsibility of the domain class to determine what it wants to source the field from within the domain process method? Something to think about. In the end, there is not always one right answer to some of these questions.

Certainly, these are some interesting questions and I hope this helps. Let us know if you have further questions.