Repeatedly looping over same Records property in Domain class

[ghost]

Hi all,

This week we have started adopting the Enterprise framework in our project and it is really interesting to discover all that it has to offer!

But there is something I can't wrap my head around yet; I have been taught to keep methods small, really small! They should do one thing and one thing only. So for instance if I need to update the owner, as well the status of a given Case record, I would separate these two operations into two small methods in the Domain layer. By doing this, I believe I increase the reusability of those methods.

However now the problem is that it seems a bit odd and expensive to call each method individually from the Service layer. With that I mean, with each method invocation in the Domain layer it enters a for loop. As each method defined in the Domain layer is looping over the Records property defined in the fflib_SObjectDomain class. This is done as such in most of the examples that I saw in the book 'Salesforce Lightning Platform Enterprise Architecture - by Andrew Fawcett' and in this sample code

I am wondering now if I should merge the two methods into one method, although it then becomes less reusable. Or if I should remove the for loop statements in the domain class and instead pull in the records from the Records property in my Service implementation class and then invoke each method in the execution block and pass a single record as an argument for processing in the respective method.
Or perhaps other suggestions?

Regards,
Jens

[wimvelzeboer]

Hi @jens-dazn,

Great to hear that you are also adopting the Enterprise patterns! In my company I hear your question often from people who are just starting to learn the framework. It is indeed true that you would want to create two separate methods iterating over all the records of the domain. Each method is just only changing their own field.
And yes, this indeed would look like a kinda CPU expensive way of doing things.

But, if the goal was to write very fast software, then we all would have been writing in Assembly code. Then you will spend a huge amount of your own CPU (your own brain :-P ) to read it. So, we need to compromise.
Since your salary is in most cases more expensive than buying an extra CPU, the balance should tip to source code that is easy to maintain and read.

The next question you might ask is; what about the limits, if we use more CPU we will start hitting the limits.
And again yes, there is a higher risk that you will hit a CPU time-out limit. That is something most frameworks have.

But luckily Salesforce have given us a wide range of feature that we can use to avoid that limit.
We need to architecture the application in a better way. For example, we can have a look at all the processes that are happening in the Trigger. Developers tend to just put all the logic in the trigger for everything that needs to happen (e.g. into an onAfterUpdate method). But should everything in that trigger needs to happen in realtime? In my experience I found that most onAfter processes can also run in near time, via queueables for example.

In your case your domain and service would indeed look something like:

public class Cases extends fflib_SObjects implements ICases
{
    ...
    public ICases setOwner(Id ownerId)
    {
        setFieldValue(Schema.Case.OwnerId, ownerId);
        return this;
    }
    
    public ICases setStatus(String value)
    {
        setFieldValue(Schema.Case.Status, value);
        return this;
    }
    ...
}

public class CasesService 
{
    public void myMethod(Set<Id> caseIds)
    {
        ...
        Id ownerId = ... ;
        ICases cases = Cases.newInstance(caseIds)
                .setOwner(ownerId)
                .setStatus('Closed');
                
        unitOfWork.registerDirty(cases.getRecords());
        ...
    }    
}

Sometimes it can be that there is one method on the domain combining two other setter methods. That method then contains domain specific business logic. Like when we need to close a case, and by doing that we need to update multiple fields on the same records. Like in this example:

public ICases closeCases()
{
    setStatus('Closed');
    setCloseDate(Date.today());   // updates a custom field Case.Close_Date__c
}

With this approach, we only need to invoke a single method in the service method.

ICases closedCases = 
        Cases.newInstance(openCaseRecords)
                .closeCases();

[ghost]

Hi @wimvelzeboer

Thank you for your elaborate response! I wasn't aware yet of the setFieldValue() method on the fflib_SObjects base class yet. Despite that it doesn't remove the need of looping over all the records in the domain with each setter method, it at least allows me to create more elegant setter methods in the domain layer. So thanks for that!

I can relate with what you are saying with regards to writing clean code vs super fast code. I guess there is simply always a trade-off between the two. So I think we just need be conscious of the decisions we make throughout the application so that we write our code in a better way.

Last, I like how in your example you're chaining the setter methods in a single method, so that you only need to invoke a single method from the service layer. I will keep that in mind!

Cheers,
Jens

[cropredyHelix]

@wimvelzeboer I should read these closed issues more often; I too did not known about setFieldValue in fflib_SObjectDomain and I've been using fflib for 7 years!

[wimvelzeboer]

@cropredyHelix actually that method was recently added as part of the new domain structure where we have a true domain with those specific getter, setter and filter methods.