chore: rough implementation of Domain Process Bindings LogicalInverse__c

[Vacster]

Simple implementation of the DomainProcessBinding__mdt.LogicalInverse__c in the Domain Process Coordinator in O(n²).

There are no tests added or updated as it seems almost impossible to create a test class for the Domain Process Coordinator. At least until the Custom Metadata Type queries are added to Force DI and then maybe something could be mocked up. Instead, I've done some simple manual tests with some basic Criteria and Action classes.

// Criteria class method that removes all Leads with LastName = 'Remove'
public List<SObject> run() {
    List<SObject> qualifiedRecords = new List<Lead>();
    for (Lead currentLead : records) {
        if (currentLead.LastName != 'Remove') {
            qualifiedRecords.add(currentLead);
        }
    }
    return qualifiedRecords;
}

// Action class that prints whatever records come inside
public with sharing class APrint extends DomainProcessAbstractAction {
    public override void runInProcess() {
        System.debug(LoggingLevel.INFO, 'APrint Reached with ' + this.records.size() + ' records!');
        for (Lead currentLead : (List<Lead>)this.records) {
            System.debug(LoggingLevel.INFO, currentLead.LastName);
        }
    }
}

This can then be tested by simply inserting Leads. With the following Anonymous Apex script:

List<Lead> leads = new List<Lead> {
  new Lead(Company = 'Potato', LastName = 'Remove'),  
  new Lead(Company = 'Potato', LastName = 'Chicken'),  
  new Lead(Company = 'Potato', LastName = 'Remove'),  
  new Lead(Company = 'Potato', LastName = 'Remove'),  
  new Lead(Company = 'Potato', LastName = 'Chicken')  
};
insert leads;

With LogicalInverse__c == False we get:

15:47:32.33 (1715377568)|USER_DEBUG|[3]|INFO|APrint Reached with 2 records!
15:47:32.33 (1715441987)|USER_DEBUG|[5]|INFO|Chicken
15:47:32.33 (1715455633)|USER_DEBUG|[5]|INFO|Chicken

With LogicalInverse__c == True we get:

15:49:18.21 (349952255)|USER_DEBUG|[3]|INFO|APrint Reached with 3 records!
15:49:18.21 (350025004)|USER_DEBUG|[5]|INFO|Remove
15:49:18.21 (350038725)|USER_DEBUG|[5]|INFO|Remove
15:49:18.21 (350048071)|USER_DEBUG|[5]|INFO|Remove

---

Why a O(n²) algorithm for this?

I originally wanted to write a simple solution like this:

List<SObject> criteriaRunResult = criteriaClazz.run();
if (currentDomainProcess.LogicalInverse__c == true)
{
    Set<SObject> qualifiedRecordsSet = new Set<SObject>(qualifiedRecords);
    qualifiedRecordsSet.removeAll(criteriaRunResult);
    qualifiedRecords = new List<SObject>(qualifiedRecordsSet);
}
else
{
    qualifiedRecords = criteriaRunResult;
}

This, however, would not work because it has the side-effect of eliminating all copies of records with an identical HashCode (i.e. all identical records). If I run the script above with this code, I get back:

15:52:50.395 (1736573077)|USER_DEBUG|[3]|INFO|APrint Reached with 1 records!
15:52:50.395 (1736651410)|USER_DEBUG|[5]|INFO|Remove

To me this seemed like an unacceptable side-effect and thus I've opted for the approach in this Pull Request.

---

This change is