Abstract Domain / DML Logic

[reignman5]

Hey guys,

really interested in learning about Apex commons as I want to implement in our org.
But I have a problem understanding a couple of things, would be great to get your take on it.

1. We have objects with different record types, so it happens that for example some currency fields are getting calculated differently but most of the logic is the same. I had hoped to solve that elegantly with apex commons but as it seems this is not really supported for trigger actions(?). I would like to have an abstract domain class for that object which gets extended by classes for each record type. On a before insert trigger it should get right class by record type. Is that even possible? Do I have to put those "variable" method in a service layer which gets called by the domain layer?
2. Imagine I have a domain class the creates a different object record onBeforeInsert(). Where would I put the dml logic? In the same domain class, in the domain class of the other object or in a service class?

Thanks for your help

[wimvelzeboer]

Hi @reignman5,

I think I would solve your first question something like this:

public with sharing class AccountTriggerHandler extends fflib_SObjectDomain 
{
   ...
  public override void onAfterUpdate(Map<Id, SObject> existingRecords)
  {
    onPartnerAccountsRecalculateCurrencyFields();
    onClientAccountsRecalculateCurrencyFields(); 
   }

   private void onPartnerAccountsRecalculateCurrencyFields()
   {
      // Here you can see that there is a domain named "Accounts"
      // with a filter method "selectByRecordType" returning a new domain 
      // with just only records of the desired recordtype. 
      IAccounts partnerAccounts = Accounts.newInstance(Records).selectByRecordType('Partner');

      // We validate that we have records in the domain, otherwise just quit.
      if (partnerAccounts.isEmpty()) return;

      // Here we have another domain specifically for Account records of the RecordType "Partner"
      // and call the recalculate functionality specifically for the Partner records
      PartnerAccounts.newInstance(partnerAccounts.getRecords())
          .recalculateCurrencyFields();
}

public virtual inherited sharing class Accounts extends fflib_SObjects implements IAccounts
{
   ...
   public IAccounts selectByRecordType(String recordTypeName)
   {
     ...
   }
   
   public virtual void recalculateCurrentFields()
   {
     // your standard logic for recalculation goes here
   }
   ...
}

public inherited sharing class PartnerAccounts extends Accounts implements IPartnerAccounts
{
  ...
  public override void recalculateCurrentFields()
  {
     // your specific recalculation logic for Partner Accounts  goes here
  }
  ...
}  

Alternatively you can have a method "recalculateCurrentFields" on "Accounts" to filter on the recordtypes instead of doing that in the trigger handler.

On your second question, The TriggerHandler method onBeforeInsert can have their own UnitOfWork that you can pass on to every service method that is invoked by the "onAterInsert" method. Something like so:

public with sharing class AccountsTriggerHandler extends fflib_SObjectDomain
{
  public override void onAfterInsert()
  {
    fflib_ISObjectUnitOfWork unitOfWork = Application.UnitOfWork.newInstance();
    AcccountsService.doSomeBusinessProcess(unitOfWork, getRecords());
    unitOfWork.commit();
  }
}

[reignman5]

Ah yes forgot about that. Definitely like the setup with TriggerHandler more. FYI the sample code is not updated with the new version.

[wimvelzeboer]

Indeed the sample code hasn't been updated yet. There is a pull-request open with a proposal with the new domain structure.

[reignman5]

Regarding question 1 I tried to set something up which is a mixture of your solution and forcecreators solution from #153 . Because I did not want to have multiple lines of code in the trigger and did not want to duplicate the code you have in "onPartnerAccountsRecalculateCurrencyFields" for every recordtype
If you have an opinion on that, I would really appreciate it.

extended the domain factory to handle recordtype map

public class DomainFactory extends fflib_Application.DomainFactory {
  protected Map<String, Type> domainByRecordType;

  protected Map<Object, fflib_IDomain> mockDomainByByRecordType;

  public DomainFactory(
    fflib_Application.SelectorFactory selectorFactory,
    Map<String, Type> domainByRecordType
  ) {
    super(selectorFactory, new Map<Object, Type>());
    this.domainByRecordType = domainByRecordType;
    this.mockDomainByByRecordType = new Map<Object, fflib_IDomain>();
  }

  public virtual fflib_IDomain newInstanceByRecordType(
    List<Object> objects,
    String recordType
  ) {
    // Mock implementation?
    if (mockDomainByByRecordType.containsKey(recordType))
      return mockDomainByByRecordType.get(recordType);

    // Determine SObjectType and Apex classes for Domain class
    Type domainConstructorClass = domainByRecordType.get(recordType);
    if (domainConstructorClass == null)
      throw new DeveloperException(
        'Domain constructor class not found for RecordType ' + recordType
      );

    Object domainConstructor = domainConstructorClass.newInstance();

    if (domainConstructor instanceof fflib_SObjectDomain.IConstructable) {
      return (fflib_IDomain) ((fflib_SObjectDomain.IConstructable) domainConstructor)
        .construct((List<SObject>) objects);
    }

    return ((fflib_IDomainConstructor) domainConstructor).construct(objects);
  }
}

Have a layer that returns a map for the domain class that extends this class

public virtual class DomainRecordType extends fflib_SObjectDomain {
  public List<SObject> newRecords { get; set; }
  public Map<String, SObject> sObjectsByRecordType{ get; set; }

  public DomainObject(List<sObject> sObjectList) {
    super(sObjectList);
    newRecords = records;
  }

  public void setMap() {
  Map<String, SObject> mapOverride = new Map<String, SObject>();
    for (sObject o : newRecords) {
      String recordTypeName = (o.getSObjectType().getDescribe())
        .getRecordTypeInfosByName()
        .get(recordTypeName);
      mapOverride .put(recordTypeName, o);
    }

    sObjectsByRecordType= mapOverride;
  }

  public class Constructor implements fflib_SObjectDomain.IConstructable {
    public fflib_SObjectDomain construct(List<SObject> sObjectList) {
      return new DomainObject(sObjectList);
    }
  }
}

Setup Application class

public class Application {

  public static final DomainFactory DOMAINBYRECORDTYPE = new DomainFactory(
    Application.Selector,
    new Map<String, Type>{
      'AccountRecordType1' => AccountsRecordType1.Constructor.class
    }
  );
}

This is calling the specified class for all the recordtype

public virtual inherited sharing class Accounts extends DomainRecordType {
  public Accounts(List<Account> accountRecords) {
    super(accountRecords);
    super.setMap();
  }

  public virtual void calculate() {
    for (String recordType : sObjectsByRecordType.keySet()) {
      ((Accounts) Application.DOMAINBYRECORDTYPE.newInstanceByRecordType(
          objectByRecordType.get(recordType),
          recordType
        ))
        .calculate);
    }
  }

public virtual inherited sharing class AccountsRecordType1 extends Accounts {
  public override void calculate() {
     // ...do something
    }
  }

[wimvelzeboer]

I have no doubt that this will work, but it is mixing the concerns a bit and would make it more complex than needed.

Now if I would have a list of records with a mix of recordTypes and create a domain for each record type, the sObjectsByRecordType would still contain all of those records.
While with a selectByRecordType only returns a domain with just those records meeting the condition

[reignman5]

Appreciate the feedback!
Which concerns would be mixed?

My code is wrong there, but every key in sObjectsByRecordType would only hold a list of records with the recordType specified in the key. So AccountsRecordType1 would be instantiated through the domain factory only with records with recordType1.

[daveespo]

Related discussion from eons ago: #153