Introduction to Design Patterns in

Salesforce

• What Are Design Patterns?

o Definition:
▪ Reusable, proven solutions for recurring design
and development challenges.
▪ Act as blueprints that provide standard
approaches to solving problems.
o Purpose:
▪ Simplify development by preventing “reinventing
the wheel.”
▪ Create a shared vocabulary among developers,
designers, and architects.
o Benefits:
▪ Efficiency: Faster development cycles through
reuse of established solutions.
▪ Consistency: Uniform behavior and appearance
across the application.
▪ Maintainability: Clear separation of concerns
leads to easier debugging and future updates.
▪ Scalability: Well-architected systems that grow
without complete rewrites.

2. Categories of Salesforce Design Patterns

A. User Interface (UI) Design Patterns

• Lightning Design System (LDS) Patterns

o Overview:
▪ A collection of repeatable design patterns and
prebuilt components that help developers create
consistent and accessible Salesforce user
interfaces.
o Core Elements:
▪ Reusable Components:
▪ Buttons, menus, modals, notifications, and
other UI elements that come with
predefined styling and behavior.
▪ Interaction States:
▪ Every component is defined by multiple
states—default, focus, hover, disabled,
pressed, and active—to ensure intuitive
user interaction.
▪ Documentation and Guidelines:
▪ Clear design specifications (size, color,
typography) and interaction guidelines
ensure that any developer or designer
knows exactly how to implement each
component.
▪ Accessibility and Branding:
▪ Components are built with accessibility in
mind (e.g., using proper contrast ratios,
alternative text, and keyboard navigation
support) while also reinforcing the
Salesforce brand.
o Best Practices:
▪ Always use SLDS components when possible.
▪ Follow detailed design specs to ensure
consistency across devices and platforms.
▪ Utilize provided guidelines to maintain an
accessible and user-friendly experience.
B. Integration Patterns

• Purpose of Integration Patterns:

o Overview:
▪ Integration patterns offer strategies for
connecting Salesforce with external systems.
They address challenges such as data
synchronization, remote process execution, and
event handling.
o Key Patterns and Their Details:
▪ Remote Process Invocation – Request and Reply:
▪ Scenario: A Salesforce process initiates a
call to an external system and waits
synchronously for a response before
proceeding.
▪ Details:
▪ Best used when the response is needed
immediately to continue the
Salesforce transaction.
▪ Involves handling potential timeouts
and ensuring that error responses are
managed gracefully.
▪ Remote Process Invocation – Fire and Forget:
▪ Scenario: Salesforce sends a request to an
external system without waiting for a
response.
▪ Details:
▪ Suitable for asynchronous operations
where the external system will
process the request independently.
▪ Ideal when immediate feedback is not
critical, thus improving user
experience by avoiding delays.
▪ Batch Data Synchronization:
▪ Scenario: Data is moved between Salesforce
and external systems in large volumes,
often on a scheduled basis.
 ▪ Details:
▪ Involves using tools like the Bulk
API to process thousands of records
efficiently.
▪ Ensures that data remains consistent
even when updates occur at different
times.
▪ Remote Call-In:
▪ Scenario: An external system calls into
Salesforce to perform CRUD (Create, Read,
Update, Delete) operations.
▪ Details:
▪ Requires robust authentication and
error handling.
▪ Often used when external systems need
to trigger actions in Salesforce in
real time.
▪ Data Virtualization:
▪ Scenario: Users can view and interact with
external data in real time without
physically importing it into Salesforce.
▪ Details:
▪ Uses adapters (such as OData) to map
external data as “external objects”
within Salesforce.
▪ Maintains up-to-date data views while
minimizing data storage in
Salesforce.
o Design Considerations:
▪ Choose between synchronous and asynchronous
integration based on business requirements.
▪ Consider data volume, error recovery, and
transaction boundaries when designing
integration solutions.
C. Apex Patterns

• Overview:
o Apex Patterns are guidelines for structuring Apex
code in a maintainable, scalable manner. They
emphasize clean separation of concerns and efficient
coding practices.

• Primary Concepts:
o Trigger Handler Pattern:
▪ Principle:
▪ Use a single trigger per object.
▪ Delegate business logic out of the trigger
into dedicated handler classes.
▪ Benefits:
▪ Simplifies unit testing and debugging.
▪ Avoids issues with multiple triggers
competing for execution order.
o Service Layer Pattern:
▪ Principle:
▪ Create a service class for each object
(e.g., AccountService, LeadService) to
encapsulate business logic.
▪ Benefits:
▪ Centralizes operations on a specific
object.
▪ Promotes code reusability and better
organization.
 o Domain and Selector Patterns:
▪ Domain Classes:
▪ Contain object-specific business rules and
validations.
▪ Encapsulate all domain logic for a single
object.
▪ Selector Classes:
▪ Centralize all SOQL queries for an object.
▪ Avoid repeating query logic across
multiple classes.
▪ Benefits:
▪ Clear separation of concerns improves
readability and simplifies maintenance.
▪ Easier to update query logic in one place
if schema changes occur.

• Additional Common Apex Patterns:

These patterns extend the basic principles and are
particularly useful for more advanced architectural
challenges.
o Singleton Pattern:
▪ Definition:
▪ Ensures that a class has only one instance
throughout the application.
▪ Provides a global point of access to that
instance.
▪ When to Use:
▪ When you need centralized control or
caching (e.g., configuration settings,
logging utilities).
▪ Advantages:
▪ Reduces memory usage by preventing
multiple instantiations.
▪ Simplifies access to shared resources.
 ▪ Considerations:
▪ Must be carefully managed to avoid issues
in multithreaded contexts or during unit
testing.
o Builder Pattern:
▪ Definition:
▪ Separates the construction of a complex
object from its representation.
▪ Allows step-by-step object creation using
a fluent interface.
▪ When to Use:
▪ When creating objects that require
multiple optional parameters or need
complex initialization.
▪ Advantages:
▪ Increases code readability.
▪ Helps manage immutable objects where all
properties must be set at creation.
▪ Example in Apex:
▪ A builder class might be used to create a
custom sObject instance with various
optional fields before performing DML
operations.
o Strategy (Policy) Pattern:
▪ Definition:
▪ Defines a family of interchangeable
algorithms encapsulated in separate
classes.
▪ The algorithm to execute is determined at
runtime based on the context.
▪ When to Use:
▪ When you have multiple methods for
processing data (e.g., different
calculation algorithms or sorting
methods).
 ▪ Advantages:
▪ Enables flexible switching between
algorithms without modifying the client
code.
▪ Enhances maintainability by isolating
algorithm-specific logic.
o Command Pattern:
▪ Definition:
▪ Encapsulates a request or action as an
object.
▪ Decouples the requester from the object
that executes the action.
▪ When to Use:
▪ When you need to parameterize methods with
different requests, queue operations, or
support undoable operations.
▪ Advantages:
▪ Provides a clear separation between the
request and execution.
▪ Makes it easier to implement features like
logging, undo/redo functionality, and
scheduling of operations.
o Facade Pattern:
▪ Definition:
▪ Provides a simplified interface to a
complex subsystem.
▪ Hides the intricacies of multiple classes
or modules behind a single, easy-to-use
interface.
▪ When to Use:
▪ When integrating with a complex API or set
of classes where a simplified interface
improves developer experience.
▪ Advantages:
▪ Reduces complexity for the client code.
 ▪ Centralizes the interactions, making
maintenance easier.
o Factory Pattern:
▪ Definition:
▪ Provides a method for creating objects
without specifying the exact class of
object that will be created.
▪ Often implemented as a static method that
returns one of several possible object
types based on input parameters.
▪ When to Use:
▪ When object creation involves complex
logic, or when the type of object to be
created might change based on conditions.
▪ Advantages:
▪ Encapsulates object creation and promotes
loose coupling.
▪ Makes it easier to introduce new types
without altering client code.
▪ Real-World Use:
▪ A factory might determine whether to
return a new instance of a standard
sObject or a custom wrapper based on
record type or context.
o General Tips for Apex Patterns:
▪ Always document your classes and methods to
describe their purpose and usage.
▪ Write unit tests to ensure that patterns
(especially those managing shared state like
Singletons) behave as expected.
▪ Use design patterns to reduce code duplication
and improve the overall structure of your
codebase.
▪ Consider the governor limits in Salesforce when
designing patterns that involve data access or
 bulk operations.

• Helper and Utility Classes:

o Purpose:
▪ Contain generic functions and logic that can be
used across various objects or modules.
▪ Examples include DateTime manipulation, common
string operations, and API integration helpers.
o Best Practices:
▪ Keep them focused on one type of functionality.
▪ Ensure that documentation is kept up to date.
▪ Use descriptive class names (e.g.,
DateTimeHelper rather than a generic
MiscHelpers).

3. Best Practices for Implementing Salesforce Design Patterns

• General Guidelines:
o Reuse Over Reinvention:
▪ Adopt patterns that have been proven in the
community (via Trailhead, Salesforce Developer
Documentation, and community blogs).
o Separation of Concerns:
▪ Isolate business logic from UI and data access
code.
▪ Maintain clear boundaries between triggers,
services, domain logic, and utility functions.
o Code Reviews and Documentation:
▪ Regularly review code to ensure that patterns
are consistently applied.
▪ Maintain detailed documentation so new team
members can quickly understand the
architecture.
 • UI Patterns:
o Follow SLDS guidelines for component usage.
o Incorporate interaction states and accessibility
best practices.
o Document design specifications and handoffs to
engineering.

• Integration Patterns:
o Analyze requirements (synchronous vs. asynchronous,
data volumes, error handling).
o Choose patterns that balance performance with
reliability.
o Use tools such as the Bulk API for high-volume data
tasks.

• Apex Patterns:
o Always limit triggers to one per object.
o Delegate logic to service or domain classes to keep
triggers “logic-less.”
o Use selector classes to centralize query logic.
o Implement additional patterns (Singleton, Builder,
etc.) where they add clarity and reduce code
duplication.

4. When and Why to Use These Patterns

• Use Cases:
o Scalable Applications:
▪ Reusable UI and Apex patterns support rapid
feature expansion without extensive rewrites.
o Maintainable Codebases:
▪ A clear architecture with separated
responsibilities simplifies debugging and
updates.
o Improved User Experience:
 ▪ Consistent UI patterns lead to intuitive user
interactions and reduced learning curves.
o Efficient Integrations:
▪ Well-chosen integration patterns enable smooth,
real-time data exchange between systems.

• Key Benefits:
o Reduced Technical Debt:
▪ A robust design minimizes the chance of code
bloat and difficult-to-maintain “spaghetti”
code.
o Faster Development:
▪ Developers can leverage prebuilt patterns and
components to speed up coding.
o Enhanced Collaboration:
▪ A common architectural language improves
communication among designers, developers, and
stakeholders.

5. Resources for Further Learning

• Salesforce Trailhead Modules:

o Identify Design Patterns – Learn to differentiate
between macro and micro patterns.

trailhead.salesforce.com
o Apex Enterprise Patterns: Domain & Selector Layers –
Deep dive into structuring Apex code effectively.

trailhead.salesforce.com
o Explore Integration Patterns and Practices –
Understand how to connect Salesforce with external
systems.

trailhead.salesforce.com

• Salesforce Developer Documentation:

 o Integration Patterns and Practices – Detailed guides
and pattern templates for integration scenarios.

resources.docs.salesforce.com

• Community Articles and Blogs:

o Articles from Salesforce Ben and Apex Hours offer
practical examples and real-world insights into
implementing Apex design patterns.

salesforceben.com

• Design System Resources:

o Lightning Design System Guidelines – Reference
materials and best practices for UI components.

lightningdesignsystem.com
o Design System Explained Efficiently – Overview and
benefits of design systems.

trailhead.salesforce.com

6. Summary

• Salesforce Design Patterns span multiple layers:

o UI Patterns: Use the Lightning Design System to
achieve consistent, accessible user interfaces.
o Integration Patterns: Implement proven methods for
connecting Salesforce with external systems in both
synchronous and asynchronous ways.
o Apex Enterprise Patterns: Structure your Apex code
using trigger handlers, service layers,
domain/selector classes, and a range of additional
patterns (Singleton, Builder, Strategy, Command,
Facade, and Factory) to ensure a maintainable,
scalable codebase.

• Adoption of these patterns leads to:

o Greater efficiency and faster development cycles.
o Reduced technical debt and easier maintenance.
o Improved consistency in both user interfaces and
backend processes.