Where to place logic, Domain vs Service? about fflib-apex-common HOT 9 CLOSED

I have challenges with 3 and 4 around the suggestion of implementing cross-object behaviour at the Domain layer, especially when they are invoked by triggers.

At worst, such a design could inadvertently cause a chain reaction of triggers which results to a variety of problems that are particularly difficult to troubleshoot and untangle without regression issues (e.g. SOQL limits, CPU time limit, trigger recursions, etc). The domain layer approach won't scale well in an org with a complex data model and business rules that grow after each iteration.

The resolution typically involves refactoring code back to a Service layer which in SFDC also implies sacrificing SFDC's standard forms (new/edit pages) with custom controller or controller extensions.

from fflib-apex-common.

Fowlers definitions...

Service Layer, “Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.” Martin Fowler / Randy Stafford, EAA Patterns

Domain Model, “An object model of the domain that incorporates both behavior and data.”, “At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with...” Martin Fowler, EAA Patterns

from fflib-apex-common.

I'd like a few views on the Type of Application Concerns i've listed above as well as other concerns we could list to help people understand where placement goes in what scenarios. I suspect sometimes just having some tightly written code in the service layer could be a preference at times to breaking things out into domain layer calcs or updates?

from fflib-apex-common.

Great feedback @jmrjulian thank you, will give this some thought!

from fflib-apex-common.

@afawcett I am building a complex subscription management system in which bulk of the business logic is invoked through triggers. There are certain scenarios where I don't want subsequent triggers to fire (stop recursion as well as chaining of triggers). Can you please provide me some guidance on that? I don't want all trigger methods to stop but want to control which ones should be skipped. Can we build something in fflib_SObjectDomain class for this?

from fflib-apex-common.

@afawcett also it would be great if we can build some control through custom settings so admins can turn on/off triggers when they want to perform certain operations like data load without invoking triggers.

from fflib-apex-common.

I think this is what you're looking for :)

https://andyinthecloud.com/2016/04/13/disabling-trigger-events-in-apex-enterprise-patterns/

Chris Mail

On 10 Jun 2016, at 11:23, mustafaturabali [email protected] wrote:

@afawcett also it would be great if we can build some control through custom settings so admins can turn on/off triggers when they want to perform certain operations like data load without invoking triggers.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from fflib-apex-common.

@mustafaturabali does at @Autobat's answer help?

(thanks btw @Autobat )

from fflib-apex-common.

I'll close this issue for now, its bene open since Feb and really was just a feedback call out. Folks can still add to this issue even though its closed.

from fflib-apex-common.