search

Coding-With-The-Force / Salesforce-Separation-Of-Concerns-And-The-Apex-Common-Library

This repo hopes to better explain Separation of Concerns for Salesforce and how to leverage the Apex Common library to employ it in your org.
86 stars 19 forks source link

DML in Service/Domain Layer #4

Open reignman5 opened 3 years ago

reignman5 commented 3 years ago

You said in one video that we should put dmls in the service layer. Does this mean, that if we have a trigger that executes on afterInsert and creates a new record (different object), this logic should go into a service layer?

Coding-With-The-Force commented 3 years ago

Although it's been a bit since I shot that video I believe I state something like, "The majority of dml should take place in a service layer 85-90%". There aren't a ton of situations that warrant dml operations outside of the service layer but every once in a while the domain layer warrants its own dml operations. If it is necessary to commit in the domain layer then it's fine to do it, just make sure it's truly object specific behavior and it's warranted to place that logic there.

reignman5 commented 3 years ago

Thanks for the quick answer. So it would not be an "anti-pattern" to call a service layer from the domain layer? Or would I call the domain class of the object I want to create?

Coding-With-The-Force commented 3 years ago

Sorry, I must've missed this, no it is definitely not an anti-pattern to do that. You can certainly call a service layer from the domain if necessary.