Adobe Commerce Developer Expert key terms

A design pattern where objects receive their collaborators from an external configuration instead of creating them directly. In Adobe Commerce, XML files in etc/ declare types, preferences, virtual types, and constructor arguments that the object manager uses to build instances.

The runtime service that instantiates classes and resolves their constructor dependencies using merged DI configuration. Developers should not call it directly in business code; it belongs only at the application entry points and composition root.

A module configuration file that defines preferences, virtual types, plugin declarations, and constructor argument values for the object manager. Files are merged across modules by area, so scope-specific overrides live in area directories.

A lightweight DI configuration entry that reuses an existing PHP class with different constructor arguments, without declaring a new class. Commonly used to create differently configured instances of the same concrete implementation.

The generated subclass that wraps a target class so plugins can run around its public methods. The framework creates it at compile time, which is why plugins cannot intercept final classes, final methods, or non-public methods.

A mechanism to extend a public method's behavior without modifying the original class, using before, after, or around methods. Around plugins wrap execution and must call the proceed callback to continue the chain.

The ordered sequence in which multiple plugins attached to the same method execute. Order is controlled by the sortOrder attribute or by before/after dependency attributes declared in di.xml.

A numeric attribute in di.xml that determines the sequence of plugins on a method, or the ordering of arguments and items in configuration. Lower values generally execute earlier in the chain.

A DI declaration mapping an interface or class to a concrete implementation, used to swap or override behavior. Preferences are global per area and are the supported way to replace a class rather than rewriting it.

A stable set of PHP interfaces (data and operation interfaces) that define a module's public API. Other modules should depend on these interfaces rather than concrete classes to reduce coupling.

An interface in a module's Api namespace that exposes getters and setters for a business entity, typically backed by a generated implementation. Used to pass structured data across module boundaries.

A service class that implements a service contract to fetch and persist entities through search criteria and data interfaces, hiding persistence details from callers. It usually delegates to a resource model or collection.

A builder-based object that expresses filters, sorting, pagination, and field selection for repository queries. Repositories translate it into collection or SQL constraints, keeping the API storage-agnostic.

The class responsible for direct database interaction for an entity, such as loading, saving, and deleting rows. It sits beneath models and repositories and typically extends the abstract database resource class.

An iterable object that represents a filtered, sorted set of entities loaded from the database. Collections build SQL lazily and support adding attributes, filters, and pagination before loading.

A versioned migration class that creates or alters database schema and data during module install or upgrade. Declarative schema has largely replaced imperative install and upgrade scripts for table definitions.

A db_schema.xml approach where table structure is declared in XML and the framework diffs it against the database to generate changes. It replaces most imperative install and upgrade scripts for schema.

A repeatable, dependency-aware class that inserts or modifies data during setup, tracked as applied so it runs once. Patches replace older data upgrade scripts and declare dependencies on other patches.

A flexible data model storing entity attributes as rows rather than columns, allowing attributes to be added without schema changes. It spreads values across backend tables based on attribute type, such as varchar, int, decimal, and text.

A named grouping of attributes assigned to a specific entity type, determining which attributes an entity of that type carries. Products and customers use attribute sets to vary their attribute composition.

A logical folder inside an attribute set that organizes attributes for display in admin forms. Groups affect presentation and organization, not the underlying storage of values.

The storage table and column definition used for an EAV attribute's values, such as varchar, int, decimal, datetime, or text. It determines which backend value table holds the data.

A class supplying the allowed option values for an attribute, used for select and multiselect inputs. It provides options for admin forms and validation rather than controlling storage.

The input renderer class that controls how an EAV attribute is edited in forms and displayed, such as text, select, or date. It is separate from the backend storage type.

An optional denormalized table that copies EAV product attribute values into columns for faster reads. It trades write complexity and rebuild cost for simpler, faster storefront queries.

A process that precomputes derived data, such as prices, stock status, or catalog search data, into dedicated tables for fast reads. Indexers run on save, by schedule, or manually, depending on mode.

The setting that controls when indexers update: on save (update on save) or by cron schedule (update by schedule). Mode affects data freshness and storefront write performance.

A named cache bucket, such as config, layout, block HTML, or full page cache, that can be enabled, disabled, or flushed independently. Types are declared in cache.xml and cleared selectively.

An identifier attached to cached entries so they can be invalidated together when related data changes. Tags let the framework clear only affected entries instead of flushing everything.

The duration a cache entry remains valid before it is considered stale. Configured per cache type or block, it balances freshness against the cost of regenerating content.

The layer that stores rendered HTML for entire pages so repeat requests skip most application work. It relies on cache identities and invalidation to serve correct, personalized-safe content.

A mechanism that renders customer-specific blocks after the page is cached, using placeholders replaced by AJAX or a separate request. It keeps personalized data out of shared page caches.

A reverse HTTP proxy commonly placed in front of Adobe Commerce to serve cached pages quickly. It is configured through a VCL file and coordinated with the application's cache invalidation.

The scheduled task system that runs jobs defined in crontab.xml, such as indexers, emails, and cleanup. It requires a configured system cron entry to trigger the application's scheduler.

A logical application scope, such as frontend, adminhtml, webapi, or crontab, that determines which DI, layout, and route configuration loads. Code must be area-aware to avoid loading the wrong configuration.

A self-contained package of code, configuration, and routes declared in registration and module XML files. Modules define dependencies, versions, and the boundaries of customization.

Declarative files that define page structure by naming containers and blocks and their relationships. Layout updates are merged per area and handle, then used to generate the rendering tree.

A view-layer class that prepares data and renders a template, participating in the layout tree. Blocks should hold presentation logic and delegate business logic to models or services.

A named layout context, derived from the route, controller, or page type, that selects which layout updates apply. Multiple handles merge to build the final page layout.

A PHTML file rendered by a block, responsible for producing HTML markup. Templates should escape output and avoid heavy data access, relying on the block for prepared data.

The build step that produces factories, proxies, interceptors, and generated data classes from DI and code declarations. Generated code is written to the generated directory and must not be edited manually.

The process that aggregates and optimizes DI configuration and generated code for production. It reduces runtime configuration parsing and is required before deploying to production mode.

The application operating mode, default or developer versus production, controlling caching, compilation, and error display. Production mode enables optimized configuration and suppresses verbose errors.

A configuration of resources and roles that governs which admin users can access specific backend features. Modules declare resources in acl.xml, and controllers check them before executing actions.