Can I pass records to domain as parameter if Domain and records related to Same object?

[maheshsomineni]

Hi Team,

I have a requirement to update records from the same object using common value in a field. Example, I have to update all the contacts with the same address if a Boolean field is checked on one contact(contact update).

For this , Is it ok to set all the contacts with same address to contacts domain and pass Contact record(which updated and worked as trigger point) as a parameter to the Contacts Domain?

[wimvelzeboer]

Hi @maheshsomineni

Which contact record would you like to update? All the contact with the same linked account, or only the contacts which are handled by the trigger?

You might also want to take a look at this example, which has some overlap with what you are looking for. It copies the Country from the Account to all the related Contact records.

[maheshsomineni]

Hi @wimvelzeboer ,

Thanks for the example. I have gone through the example given.
I have to update the records handled by the trigger and also the records in the database on the same object.

In the example provided, I can see a map passed to the Domain with ID as Key and Country as Value.

But for my example, I have to pass Id as Key and entire Record(need 3 fields from the record to populate in non-triggered records in the same object) from the Trigger.

Instead of passing three maps(Map<Id,String>) to the Domain setters, I am trying to pass List<Id,Object>. Is that Okay in Domain Layer?

with Map<Id,String>

public IObjectRecs setField1(Map<Id,String>){
//Iterate records and Set value in Field1 in the records not in trigger handler
}
public IObjectRecs setField2(Map<Id,String>){
//Iterate records and Set value in Field2 in the records not in trigger handler
}
public IObjectRecs setField3(Map<Id,String>){
//Iterate records and Set value in Field1 in the records not in trigger handler
}

with Map<Id,Sobject>

public IObjectRecs updateFields(Map<Id,SObject>){
   for(Sobject objectRec : getRecords())//getRecords() contain non-trigger records
  {
     //Access map and get Triggered record from the map Parameter
    setField1(SobjectRec.Field1);
    setField2(SobjectRec.Field2);
    setField3(SobjectRec.Field3);
  }
}

with Map<Id,Sobject> , I am trying to avoid 2 maps and 2 for loops. Is this okay?

Thank you so much for your explanation and time , Wim

[wimvelzeboer]

Hi @maheshsomineni ,

looking at the SOLID design principles the idea is to create small methods doing only one thing.
If you would have one method doing multiple things, like in your example updateFields(Map<Id,SObject>), then what is the chance that some other part of your application can reuse that method?

Having one method on the domain setting a single field value will increase the chances of reuse for that method.
So, in the case of dealing with three fields, I would still use separate methods, something like:

IAccounts accounts = Accounts.newInstance(accountRecords);
IContacts contact = Contacts.newInstance(ContactsSelector.newInstance().selectByAccountId(accounts.getRecordIds()));
contacts
   .setMailingCountryByAccountId(accounts.getShippingCountryById())
   .setMailingStateByCountryId(accounts.getShippingStateById())
   .setMailingCityByCountryId(accounts.getShippingCityById());

Remember, it is not your first priority to write fast software, but to write readable & scale-able applications that re-use code and are easy to maintain. If it were the goal to write fast software, then everyone would be writing in assembly.

If you are hitting Salesforce limits, then it is usually time to re-think your architecture. Things like; does everything in your onAfter* trigger really need to be executed in real-time, or it is OK to use things like Queueable Apex?

[maheshsomineni]

Hi @wimvelzeboer ,

Thanks for explanation. Need some more inputs.
Here my idea is not write 3 setters in one method. I will have one method in domain with Map<Id,Sobject> and while iterating getRecords(), I will call three setters. Is that Okay?
public IObjectTestRecs updatefields(Map<Id,Sobject> maptest) { for(Sobject obj : getRecords) { Sobject triggeredRec = maptest.get(obj.Field5); setField1(triggeredRec.Field1); setField2(triggeredRec.Field2); setField3(triggeredRec.Field3); } } setField1(String Value1){ //set value } setField2(String Value1){ //set value } setField3(String Value1){ //set value }

This way, I am trying to avoid multiple maps and for loops and making the setter also reusable.

Is this okay? Can I pass Map<Id, Sobject> to one method and that method will call required setters ?

Also, if you have an example in which Trigger point and update are on the same object, Please provide the link

Again Thanks for your time and explanation, Wim

[wimvelzeboer]

The idea is that every single method of the domain iterates over ALL the records in the domain.

So, if you look at my example again, the setter method would look something like:

Contacts Domain (using fflib-apex-common)

public IContacts setMailingCountryByAccountId(Map<Id, String> countryNameByAccountId)
{
  for (Contact record : (list<Contact) getRecords())
  {
    if (countryNameByAccountId.contains(record.AccountId) == false) continue;
    
    record.MailingCountry = countryNameByAccountId.get(record.AccountId);
  }
  return this;
}

or it would look like this (using fflib-apex-extensions)

public IContacts setMailingCountryByAccountId(Map<Id, String> countryNameByAccountId)
{
  setFieldValue(Contact.AccountId, Contact.MailingCountry, countryNameByAccountId);
  return this;
}

And the method on the service / trigger handler would look like:

public void myBusinessFunction(List<Account> accountRecords)
{
  IAccounts accounts = Accounts.newInstance(accountRecords);
  IContacts contact = Contacts.newInstance(ContactsSelector.newInstance().selectByAccountId(accounts.getRecordIds()));
  contacts
    .setMailingCountryByAccountId(accounts.getShippingCountryById())
    .setMailingStateByCountryId(accounts.getShippingStateById())
    .setMailingCityByCountryId(accounts.getShippingCityById());
}

[maheshsomineni]

@wimvelzeboer , Thanks for the detailed explanation, Wim