Platform and Application Architecture
Platform and Application Architecture
This domain tests how you structure an application on the Salesforce platform: separation of concerns, declarative versus programmatic boundaries, asynchronous design, modularity, and multi-org strategy.
Layers
- Presentation: Lightning Web Components, Experience Cloud, mobile - thin, with no business logic.
- Automation: Flow for orchestration and approvals; record-triggered logic in triggers when bulk behaviour and transaction control matter.
- Domain and service: Apex trigger handler framework (one trigger per object), service classes for reuse, selector classes isolating SOQL.
- Data: objects and external objects.
- Integration: Named Credentials, Platform Events, callouts behind an interface.
Rules that hold
Declarative first when the result is maintainable; code when you need bulkification, transaction control, complex algorithms, or testability - not for prestige. One automation tool per concern, documented, because the order of execution can otherwise produce logic that depends on incidental sequencing. Callouts cannot follow DML in the same transaction, so move them to asynchronous execution. Asynchronous options: future methods, Queueable (with chaining and finalizers), Batch Apex, and scheduled jobs. Custom metadata deploys with configuration; custom settings do not, which matters for environment promotion.
Worked example
A trigger calls a tax service for every order line. Synchronously, 200 lines mean 200 callouts, latency, and probable limit failure. Move the callout to a Queueable job: the trigger enqueues a job per order, the job chunks lines, calls the service once per chunk, writes results back, and increments a retry counter on failure. The UI shows "tax pending" until the result lands. This demonstrates the async boundary, idempotency, and graceful degradation - the three things the panel looks for.
Traps that cost marks
Business logic spread across Flow, workflow, and triggers. Recursion. Multiple triggers per object. Callouts after DML. Using custom settings for configuration that must deploy. A monolithic trigger that cannot be unit tested. Ignoring the multi-org question until it becomes a data-sharing problem.
Key points
- One trigger per object, with handler, service, and selector layers.
- Callouts belong in asynchronous contexts, never after DML.
- Choose one automation tool per concern and document it.
- Custom metadata travels between environments; custom settings do not.
- Queueable chaining and finalizers handle long-running orchestration.