Patterns are more important than frameworks.
There. I said it. Blasphemy right? When it comes to Salesforce triggers, it’s common to think about frameworks. What’s the best framework to use? Should I find one or create my own? A framework can offer efficiency – code reuse and code you don’t have to write yourself. It can provide discipline – everybody has to use the framework. It can improve reliability and maintainability, and make problems easier to debug.
And in a brand new org with a single development team, you can make it work – 100% enthusiastic adoption.
But we live in the real world. And real orgs are often.. well, a mess. Or, to adopt a more Orwellian term- a “Happy Soup”. There are multiple development teams, some of whom don’t talk to each other. There’s no way they would all agree on a single framework. And the cost and risk of rewriting existing code into a framework is prohibitive. Nobody knows what half the code actually does anyway.
That’s right, in the real world, trigger frameworks are not nearly as useful as they sound. But that doesn’t mean you should give up. As it turns out, it’s possible to apply the same design patterns that trigger frameworks use when working in “Happy Soup” orgs. It’s possible to make small incremental changes that have massive benefit. In fact, you can achieve most of the benefits of a trigger framework at almost no cost and no risk.
You can find out how in my new Pluralsight course “Adopting Trigger Design Patterns in Existing Salesforce Orgs“.
Enjoy!
80’s and 90’s was the design pattern booming era. So many good books of patterns/principles.
After that things shift to frameworks. Nowadays, CVs of programmers are full of “I know how to use xyz framework”.
It doensn’t mean frameworks are bad, it’s just that framework doesn’t train the mindsets that design patterns train ppl.
Good to see your article and new pluralsight course again, Dan.
This is one of things from your 4th edition book that I didnt fully get yet.
Hi Dan,
This is sheenam.
I have seen your course trigger pattern.
I got a question. One of the concept where you accumulated dmls by use object updater class ( simpleleadupdater). You used it in trigger which can cause dependency while trying to modularized org.
How would you address this case?
There’s no one answer to this question. “Modularizing” is an architectural question – setting the module boundaries depends very much on the specific org and applications. You could certainly decouple the updater class from the rest of the trigger framework, but it’s equally valid to bind the updater to the framework (keep the dependency) and do the decoupling at the trigger level.
Regardless of where you choose to set the module boundaries, the mechanism is the same (define global interfaces for a base module, or use system.callable).