Real-World Scenario

Imagine this common situation:

You have validation logic when Opportunity is marked Closed Won.
Later, the same rule is needed for:

● Data Loader imports
● Flow updates
● REST API integrations

If logic is written only inside a trigger, you must duplicate logic or break automation consistency.

Design patterns solve this by:

● moving logic to reusable service classes
● keeping triggers thin
● allowing multiple entry points

This is how enterprise Salesforce projects are built.

What Are Design Patterns?

Design patterns are reusable architectural templates that describe how classes and objects should interact to solve specific problems.

They are not code libraries.
They are ways of structuring your code.

In Salesforce projects, patterns are used to:

● Reduce duplicate logic
● Separate responsibilities
● Improve readability
● Support team development
● Simplify testing

Patterns guide how you write code, not just what code you write.

Why Apex Projects Need Design Patterns

In small demos, we often write:

trigger AccountTrigger on Account (before insert, after update) {
    if(Trigger.isInsert){
        // validation logic
    }
    if(Trigger.isUpdate){
        // update logic
    }
}

This may work initially, but as business rules grow:

● Triggers become very large
● Logic becomes tightly coupled to triggers
● Reusing logic from LWC, Flow, or API becomes difficult
● Test classes become complex
● Small changes cause unexpected failures

Design patterns help move logic out of triggers and controllers into reusable services.

Demo Concept: From Trigger Logic to Service Pattern

◆ Step 1 – Business Requirement

When Opportunity Stage becomes Closed Won:

● Set Close_Won_Date__c
● Send notification logic (simulated)

Design Pattern Approach

Trigger

trigger OpportunityTrigger on Opportunity (before update) {
    OpportunityTriggerHandler.beforeUpdate(Trigger.new, Trigger.oldMap);
}

Handler

public class OpportunityTriggerHandler {

    public static void beforeUpdate(List<Opportunity> newList,
                                     Map<Id, Opportunity> oldMap) {

        OpportunityService.handleStageChange(newList, oldMap);
    }
}

Service (Business Logic)

public class OpportunityService {

    public static void handleStageChange(List<Opportunity> newList,
                                         Map<Id, Opportunity> oldMap) {

        for(Opportunity o : newList){
            Opportunity oldOpp = oldMap.get(o.Id);

            if(o.StageName == 'Closed Won' &&
               oldOpp.StageName != 'Closed Won') {

                o.Close_Won_Date__c = System.today();
            }
        }
    }
}

Now This Logic Can Be Used By:

● Triggers
● Batch Apex
● REST APIs
● Invocable Methods for Flows

Same logic, multiple entry points — that is design thinking.

Benefits of This Structure

● Clear responsibility per class
● Easier debugging
● Simple unit testing
● Logic reuse across platform
● Less risk when changing requirements

This is the foundation for applying advanced patterns like Factory, Strategy, and Unit of Work later in this phase.

When Not to Use Heavy Patterns

Design patterns are powerful, but overusing them can also create problems.

Avoid patterns when:

● Project is very small
● Logic is extremely simple
● Team is not familiar with patterns
● Over-engineering adds confusion

Patterns should solve problems — not create complexity where none exists.

Start simple, and introduce patterns when complexity appears.

Conclusion

In this blog, you learned why design patterns are essential for building scalable Apex applications.

Design patterns help you write Apex that survives changing requirements and growing complexity.

Design smart today so your code stays strong tomorrow. Happy coding! 🚀

Apex Beginner to Advance

Apex Design Patterns: Why They Matter