Adobe Commerce Architecture and Development Fundamentals
Adobe Commerce is a PHP application built on top of the Magento Open Source codebase, extended with Adobe cloud services and B2B capabilities. The request lifecycle is the single most tested concept: index.php bootstraps app/bootstrap.php, the Magento\Framework\App\Bootstrap object builds the application, and the front controller (Magento\Framework\App\FrontController) routes the request. Routing resolves in order: a matching routes.xml in a module's etc/frontend (or etc/adminhtml) area, then the standard router, CMS router, and default router. Areas (frontend, adminhtml, webapi_rest, crontab, graphql) each have their own DI configuration, so a preference declared only in etc/di.xml does not apply to the admin area - a classic trap.
Dependency injection is configured through di.xml files merged across modules, with type, preference, virtualType, and plugin nodes. Object Manager is a service locator; production code should receive dependencies via constructor injection. Plugins (interceptors) run before, around, and after methods; around must call $proceed(), and plugins cannot intercept final methods, non-public methods, or objects created with new.
Caching and indexing are architectural, not just operational. Cache types are declared in etc/cache.xml; indexers in etc/indexer.xml and mview.xml. Understand that the cache is keyed by cache type plus an ID built from configuration and request context, so changing a layout or config invalidates specific types.
Worked rule of thumb: If a question asks where to change a class globally, answer di.xml preference in the correct area; if it asks to change behavior for one class only, answer a plugin. If the behavior must apply in both storefront and admin, declare it in the global etc/di.xml, not the area-specific file.
Watch for traps around around plugins returning null, plugin sort order (sortOrder), and the difference between a virtualType (no PHP class) and a preference (maps interface to implementation).