Salesforce Enterprise Patterns

Salesforce is a powerful platform for enterprise CRM and business automation. Large, long-lived Salesforce implementations benefit from a small set of architectural practices that improve maintainability, testability, and scalability. The following is an original summary of the core ideas promoted by the Apex Enterprise Patterns (ApexHours) resource, with a link for deeper reading.

Overview

Apex Enterprise Patterns focus on organizing Apex code into clear layers and responsibilities so teams can scale development across features and releases. Key themes are separation of concerns, testability, centralized data access, and small focused classes that are easy to read and mock in tests.

Layered Architecture (Domain / Service / Selector)

• Domain layer: Encapsulates business rules for a specific SObject or aggregate and exposes unit-testable operations. Use domain classes to keep logic out of controllers and UI components.
• Service layer: Orchestrates higher-level flows that may touch multiple domain objects, coordinate transactions, or call external systems. Services should be thin coordinators that are easy to unit test.
• Selector (Data access) layer: Centralizes SOQL and query logic. Selectors provide reusable methods for fetching records and guarding against redundant queries or security gaps; this makes query tuning and pagination safer and easier to maintain.

Selector Pattern & SOQL Centralization

• Keep your SOQL queries in one place (selector classes) rather than spread across controllers and services.
• Provide parameterized methods (filters, pagination, field sets) and return typed DTOs or sObject collections.
• Protect against N+1 query problems by designing selectors that accept bulk identifiers.

Testability & Mocking

• Structure classes so behavior can be unit-tested without performing real DML or HTTP calls.
• Favor small pure functions in the domain layer and isolate side effects in service classes that can be stubbed or mocked in tests.

Bulkification & Governor Limit Awareness

• Write methods that accept collections and process records in bulk. Avoid performing DML inside loops.
• Use Queueable/Batchable patterns for long-running or high-volume operations and platform events for decoupled integrations.

Integration & External Systems

• Use named credentials and retry/backoff strategies for outbound calls.
• Keep integration logic in the service layer and surface clear failure-handling strategies (retries, dead-letter, alerting).

Packaging & Modularity

• Organize code into cohesive modules (domain + selectors + services) that represent a bounded business capability.
• Keep interfaces small and prefer composition over inheritance to make code easier to reuse.

Observability & Ops

• Emit structured logging for key business events and capture metrics for integration success rates and queue processing.
• Use monitoring/alerting for failed batches, slow integrations, and test coverage regressions.

Practical Next Steps (for this post)

• If you want, I can append a small set of example Apex snippets to illustrate: a selector method, a domain class with a bulked update, and a service method that coordinates a transaction and calls a selector. These will be original examples inspired by the patterns (not copied verbatim) and will be attributed to ApexHours for further reading.

Attribution

This summary is an original paraphrase prepared as a companion to the Apex Enterprise Patterns material on ApexHours: https://www.apexhours.com/apex-enterprise-patterns/. For the full, canonical treatment including code samples and guided explanations, please see that resource.