Strategic Guide — Glossary
Supplementary to the Strategic Guide.
Primary reader: Anyone who hits an unfamiliar term in one of the other Strategic Guide docs. Look up the term, then go back to where you were. This glossary covers the framework terms you will see in code, in metadata, in your own components, and in the surrounding Salesforce platform.
Table of Contents
Architecture Layer Map
Where major framework terms fit in the KernDX stack:
text
Presentation: ComponentBuilder, LWC
Services: FLOW_*, API_Inbound, API_Outbound, REST_*
Domain: TRG_Base, IF_Trigger, Validation Rules
Data Access: SEL_Base, QRY_Builder, DML_Builder
Infrastructure: LOG_Builder, UTIL_Cache, UTIL_CircuitBreaker, UTIL_Retry
Configuration: TriggerAction__mdt, ApiSetting__mdt, FeatureFlag__mdtFramework Terms
| Term | Definition | Example | Related Sections |
|---|---|---|---|
| Amoss | Apex Mocking Objects Simply and Safely: a general-purpose mocking and stubbing library for Apex tests. It uses a fluent (chainable) API for defining mock behaviour. | Amoss_Instance controller = new Amoss_Instance(MyClass.class); controller.expects('method').returning(value); | |
| Anti-Corruption Layer | Pattern that isolates domain model from external systems by translating between different models. | A DTO layer converts external API JSON to internal domain objects. | Architecture & Philosophy — Module Inventory |
| Apex Cursors | Database cursor API (GA Spring '26) enabling processing of up to 50 million rows by fetching results in configurable chunks via cursor.fetch(position, count). | Database.getCursor(query).fetch(0, 200) returns the first 200 records. | Adoption — Modern Platform Features |
| apex-mockery | Open-source mocking library for Apex unit tests, hosted under the Salesforce GitHub organisation. Provides general-purpose stub/mock creation without domain-specific features. | MockFactory.create(MyInterface.class) creates a test double. | |
| ApexTestKit | Open-source test data generation library providing a fluent API for creating test SObjects with automatic field population. | ATK.prepare(Account.SObjectType, 200).build().save(); | |
| API_MockFactory | KernDX's two-tier mock resolution system for web service testing. Resolves mocks from memory (programmatic) or custom metadata (ApiMock__mdt), with call verification and fault simulation. | API_MockFactory.forService('API_SendEmail').body('{"id":"123"}').statusCode(200).register(); | Architecture & Philosophy — Module Inventory |
| Application Layer | fflib layer that coordinates use cases, typically invoked by UI or API. | AccountsServiceImpl coordinates account creation workflow. | |
| Atlas Reasoning Engine | Salesforce's AI reasoning system (announced Dreamforce 2024, Agentforce GA October 2024) powering Agentforce agents, using a ReAct (Reason-Act-Observe) loop to classify topics, select actions, and achieve goals. | Atlas evaluates the user request, plans actions, executes them, and reflects on results. | Adoption — Agentforce Implications |
| Bounded Context | DDD concept: explicit boundary within which a domain model is defined and applicable. | "Account" means customer in Sales context, billing entity in Finance context. | |
| Bulkhead Pattern | Resilience pattern that isolates resources to prevent cascading failures. | Separate Queueable chains for critical vs. batch operations. | Architecture & Philosophy — Module Inventory |
| Bypass Audit Emission | A KernDX safeguard. Whenever someone turns off (bypasses) a trigger and then changes data, KernDX records an audit log entry noting what ran, which bypass was used, the target object, and an optional reason. Because the entry is written as a Salesforce Platform Event, it is kept even if the surrounding transaction is rolled back. So someone cannot bypass a trigger, make a change, and undo the transaction to hide that it happened: the audit trail remains. (Implemented in TRG_Base.) | You call kern.TRG_Base.bypass(Account.SObjectType) during a data load; the call writes a bypass audit log visible in the log dashboard whether or not the data load itself rolls back. | Architecture & Philosophy — Trigger Framework, Security - Guide |
| Change Data Capture (CDC) | Salesforce feature publishing events when records change, enabling near-real-time data replication. | CDC events stream Account changes to an external data warehouse. | |
| Circuit Breaker | After repeated failures the framework stops calling a failing external system for a cool-off, then resumes, so one struggling integration does not keep tying up your transactions. Three states: CLOSED (normal), OPEN (blocking), HALF_OPEN (testing). | After 5 consecutive API failures, circuit opens for 5 minutes. | Architecture & Philosophy — Module Inventory |
| Code Drift | The gradual drift towards inconsistent, unpredictable code as a codebase grows, especially when several teams work on it. The more this happens, the longer new people take to onboard, the slower incidents are to diagnose, and the less confident anyone is about refactoring. It comes from how you run the work, not from which licence a tool uses. | Where many system integrators share an org with weak central enforcement, separate-library stacks carry a High risk of this drift, while an integrated framework carries Medium risk. | Adoption — Code Drift |
| ComponentBuilder | A KernDX base class for Lightning Web Components that comes with the common wiring already built in, so you do not rebuild it in every component. You extend it instead of raw LightningElement and switch on only the pieces you need (notification, controller, navigation, lightning-message, flow-navigation). | export default class MyComponent extends ComponentBuilder('notification', 'controller') { ... } | Architecture & Philosophy — LWC |
| CQRS (Command Query Responsibility Segregation) | Pattern that uses separate models for reading (queries) and writing (commands) data, enabling independent optimisation of each path. | Selector classes handle reads while a Unit of Work or DML facade handles writes, with each path optimised independently. | Adoption — Core Pattern Comparison |
| Data Masking Framework | Redacts sensitive text before it is saved, configured with metadata rather than code, for any SObject's text fields: standard objects, custom objects, and platform events. It runs as a before-insert, before-update, or before-publish step on the trigger dispatcher, rewrites the sensitive content in memory, and saves only the redacted value. You configure it with MaskingRule__mdt and MaskingTarget__mdt. It is on by default at the framework master off-switch (kill-switch) level, then you opt in per SObject with MaskingTarget__mdt + TriggerSetting.ApplyMasking__c = true, so you only pay the masking cost where the data warrants it. Four pattern modes: Regex, JsonKey, ExactMatch, CreditCard (a pattern match combined with Luhn validation). This is different from Shield Platform Encryption (encrypts data at rest, keeps the original) and Salesforce Data Mask (sandbox-only, runs after a copy). | A MaskingTarget__mdt record wires the shipped MaskPaymentCard rule onto Case.Description so any 13–19 digit sequence that passes Luhn validation pasted into a case comment is redacted before the record is persisted. | Architecture & Philosophy — Module Inventory, the Data Masking comparison |
| Dead Letter Queue | Messages or requests that fail after all retries are set aside here for inspection, not silently lost, so you can investigate and recover them by hand. | After 3 failed retries, an ApiCall__c record is moved to dead letter status with full error context. | Architecture & Philosophy — Module Inventory |
| Domain Layer | fflib layer containing business logic and validation rules. | Accounts domain class validates account naming conventions. | |
| Domain-Driven Design (DDD) | Software design approach that models complex business domains using ubiquitous language. | fflib's domain/selector/service separation mirrors DDD patterns. | |
| DTO (Data Transfer Object) | A small class holding exactly the fields you want to move in or out, that converts itself to and from JSON. In KernDX, DTOs extend DTO_JsonBase with @JsonAccess annotations. | DTO_AccountRequest carries HTTP request payload. | Architecture & Philosophy — Module Inventory, Adoption — Core Pattern Comparison |
| Dynamic Routing | Inbound request routing by URL path and HTTP method, with wildcard support. Configured via ApiSetting__mdt custom metadata. | A single @RestResource endpoint routes /v1/accounts/* to different handler classes based on HTTP method. | Architecture & Philosophy — Module Inventory |
| ESAPI (Force.com Enterprise Security API) | Salesforce's legacy security library providing CRUD/FLS enforcement, output encoding, and input validation. Largely superseded by platform-native features (USER_MODE, stripInaccessible()). | ESAPI.accessController().isAuthorizedToView(Account.SObjectType, fieldList) | |
| Fluent API | API design pattern where methods return this to enable method chaining for readable, expressive code. | QRY_Builder.selectFrom(Account.SObjectType).condition(...).toList() | |
| Governance Readiness | A three-level way to describe how well your org can enforce architectural standards: Level 1 (Tactical Delivery Org, no central authority), Level 2 (Controlled Enterprise, a central architecture function), Level 3 (Platform-as-Product Org, a dedicated platform team with CI enforcement). Which framework fits you depends on this level. | A Level 1 org with several system integrators and no architecture board is at high risk of code drifting towards inconsistent patterns; an integrated framework gives teams fewer separate choices to make, but you still need a minimum of governance. | Adoption — Code Drift |
| Idempotency | If the exact same request arrives twice, the first result is returned again instead of being re-run, so a duplicate retry does no harm. KernDX builds this in with a configurable time-to-live (TTL). For inbound calls it checks a hash of the request body: if the same idempotency key arrives with a different body, the framework rejects it with HTTP 409 rather than silently duplicating or masking the change. | An inbound API call checks a hash of its body; if the same idempotency key arrives with a different body, the framework returns HTTP 409 instead of processing the call. | Architecture & Philosophy — Module Inventory |
| Metadata-Driven Trigger | Trigger framework where handler execution is configured via Custom Metadata Types rather than hardcoded in trigger body. | TAF and KernDX TRG_* both use custom metadata to register and order trigger actions. | |
| Mock | Test double that simulates external dependencies. | API_MockFactory registers predefined HTTP responses for testing. | |
| Named Query API | Spring '26 feature exposing SOQL queries as REST endpoints without custom Apex code. | Define a named query in Setup; access via /services/data/v67.0/named/query/QueryName. | Adoption — Modern Platform Features |
| Platform Events | Salesforce publish-subscribe event mechanism for asynchronous, loosely-coupled communication. Base delivery allocation is 50,000/24hr for Performance/Unlimited editions (shared with CDC). | LOG_Builder publishes log events via the LogEntryEvent__e platform event. | |
| Prompt Caching | LLM provider feature (available from major providers as of 2025) that caches repeated system prompt prefixes, reducing input token costs by approximately 90% for subsequent requests that share the same prefix. Behaviour and pricing vary by provider. | An AGENTS.md instruction file sent as a system prompt is cached after the first request; subsequent requests pay only ~10% of the input token cost for those instructions. | Adoption — AI Context Files |
| RunRelevantTests | Spring '26 deployment test level (Beta) that automatically identifies and runs only tests relevant to the deployment payload. Limitations: Does not detect tests for dependent metadata (e.g., a trigger action's tests may not run when deploying only the trigger); not recommended for production deployments until GA. | sf project deploy start --test-level RunRelevantTests | Adoption — Modern Platform Features |
| Safe Mode | A KernDX dry-run mode that lets you test API handlers against real data without saving anything: every database change is rolled back automatically. You turn it on from the API Test Harness LWC, no code required. | The API Test Harness LWC invokes an outbound API in Safe Mode; the response is returned but no records are created or modified. | Architecture & Philosophy — Module Inventory |
| Saga Pattern | Coordination pattern for distributed transactions that uses a sequence of local transactions, each publishing events to trigger the next step, with compensating transactions for rollback. | An order process spans Opportunity close, inventory update, and invoice creation, where each step is a separate transaction with rollback capability. | Architecture & Philosophy — Module Inventory |
| Selector | Pattern for encapsulating SOQL queries with default field sets and reusable query methods. In KernDX, selectors extend SEL_Base and expose findById(), findByField(), etc. | new SEL_Accounts().findById(accountId) retrieves an Account with default fields. | Adoption — Core Pattern Comparison |
| Semi-Join | SOQL pattern using subquery in WHERE clause to filter by related records. | WHERE Id IN (SELECT AccountId FROM Opportunity WHERE StageName = 'Closed Won') | |
| Separation of Concerns (SoC) | Design principle that separates code into distinct sections, each addressing a separate concern. | fflib separates domain logic, data access, and orchestration. | Architecture & Philosophy — Integrated Stack |
| Service Layer | fflib layer that orchestrates complex operations across multiple domains. | AccountsService coordinates account creation + contact creation + opportunity creation. | |
| SYSTEM_MODE | A Salesforce platform AccessLevel that skips all of the running user's permission checks (object create/read/update/delete, field-level security, and record sharing). It is meant for framework-internal reads of configuration metadata and audit tables, where the running user's permissions are not relevant. You opt in per call with .withSystemMode() on kern.QRY_Builder / kern.DML_Builder, per selector by overriding systemModeRequired() on kern.SEL_Base, or org-wide through feature-flag master off-switches (kill switches) for emergency rollback. | Your selector reading kern__ApiSetting__mdt overrides public override Boolean systemModeRequired() { return true; } so the selector works no matter what access the running user has to the metadata. | Security - Guide, the competitive analysis |
| systemModeRequired() hook | A virtual method on kern.SEL_Base that you (or a framework selector) override to pin a selector's queries to SYSTEM_MODE no matter what the flag-driven default is. It returns false by default. 33 framework selectors set it to true: the ones that read metadata, audit tables, or permission records, where enforcing USER_MODE would silently break the framework. | kern.SEL_User overrides the hook to true so context-user lookups succeed even when the running user lacks View All Users. | Selectors - Guide, Security - Guide |
| Transactional Outbox | Pattern ensuring local transaction and event publication are atomic by writing events to a local table first. | An integration writes its outbound requests to a queue record in the same transaction as the business data, and a separate process sends them afterwards. KernDX does not implement this pattern: API_Outbound dispatches in the calling transaction, records every routed call, and sets aside any call that fails every retry rather than losing it. | |
| Trigger Handler | Class that contains trigger logic, invoked by trigger. | TRG_SetAccountDefaults implements IF_Trigger.BeforeInsert. | |
| TST_Mock.MockBuilder | KernDX's fluent mock builder (inner class of TST_Mock) that wraps TST_Builder and auto-registers results with TST_Mock for DML-free query interception. Enables unit tests without database operations. | TST_Mock.of(Account.SObjectType).withOverride(Account.Name, 'Test').build() creates an in-memory mock and registers it for selector queries. | |
| Ubiquitous Language | DDD practice of using consistent terminology across code and business conversations. | Use "Opportunity" not "Deal" if business uses that term. | |
| Unit of Work (UoW) | Pattern that maintains a list of objects affected by a transaction and coordinates writing changes. | fflib_SObjectUnitOfWork batches inserts/updates and commits atomically. | Adoption — Core Pattern Comparison |
| USER_MODE | A Salesforce platform AccessLevel that runs with the current user's permissions enforced on every SOQL query and DML operation: object create/read/update/delete (CRUD), field-level security (FLS), and record sharing. Any field the user cannot read is stripped from results; any object the user cannot update raises a SecurityException. KernDX QRY_Builder and DML_Builder default to USER_MODE. | kern.QRY_Builder.selectFrom(Account.SObjectType).toList() runs in USER_MODE by default. An integration user without read access on Account.SSN__c sees null in that field even though the SOQL selected it. | Security - Guide, the competitive analysis |
| W3C Distributed Tracing | An industry standard for carrying one tracking ID across service boundaries using the traceparent HTTP header, so a single user action can be followed from one system to the next. KernDX keeps the trace ID flowing across inbound and outbound API chains automatically. | An inbound API receives a traceparent header; KernDX preserves the trace ID on subsequent outbound calls, enabling end-to-end request correlation. | Architecture & Philosophy — Module Inventory |
Common Confusions
Pairs that new readers frequently conflate:
Selector vs Query Builder. A selector (SEL_*) is a reusable class for a specific SObject with default fields and named query methods (e.g., findById, findOverdue). A query builder (QRY_Builder) is the underlying fluent (chainable) API for constructing any SOQL query. Selectors use the query builder internally via the inherited query property.
Trigger Dispatcher vs Trigger Action. The dispatcher (TRG_Dispatcher) reads trigger context and routes execution to registered handlers. A trigger action (e.g., TRG_SetDefaults) is a handler class that implements business logic for a specific event. One dispatcher per object; many actions per object.
TST_Builder vs TST_Mock. TST_Builder creates real SObject records (inserted to the database or held in-memory). TST_Mock creates in-memory records AND registers them for query interception, enabling DML-free unit tests where selectors return mock data without database round-trips.
Feature Flag vs Custom Setting. FeatureFlag__mdt is KernDX's metadata-driven feature toggle with strategy support (percentage rollout, permission-based, date-range activation). Custom Settings are a Salesforce platform primitive with no built-in strategy or hierarchy.
TriggerSetting vs TriggerAction (metadata). TriggerSetting__mdt defines which SObject has a trigger dispatcher (one record per object). TriggerAction__mdt registers a specific handler class for a specific event on that object (many records per object). A TriggerAction__mdt record always points to a parent TriggerSetting__mdt via TriggerSetting__c.
USER_MODE vs SYSTEM_MODE. Both are Salesforce platform AccessLevel values. USER_MODE enforces the running user's CRUD/FLS/sharing on every SOQL and DML operation. SYSTEM_MODE bypasses them. KernDX QRY_Builder and DML_Builder default to USER_MODE; you opt in to SYSTEM_MODE per-call (.withSystemMode()), per-selector (systemModeRequired() override), or org-wide (feature-flag kill switch).