Global Reference Architecture Patterns
Next to “no GRA pattern” there are four styles of GRA patterns.
No GRA pattern
When a GRA pattern is not used, each Adobe Commerce instance is a unique application. There is no code reuse, except by manually moving code from one instance to another. These copies always diverge. The amount of effort to ensure that each instance has the same changes but still works as expected can become overwhelming. In this scenario, three instances need three times the maintenance effort of one instance.
The split Git GRA pattern
This pattern consists of Git repositories for development and one Git repository per instance. Each file in the instance is maintained in one of the development repositories. They come together as a braid forming the whole GRA. Each line of code only exists in a single development repository and is installed to the instances using the braiding technique, leading to code reuse.
The bulk packages GRA pattern
The Adobe Commerce core and third-party modules are directly installed through Composer repositories. Git repositories can be used as Composer repositories. In this pattern, the entire GRA shared codebase is hosted in a single or a few Git repositories and installed through Composer. The key characteristic is that multiple modules, language packs or themes are hosted in a single composer package, simplifying development.
The separate packages GRA pattern
Each Adobe Commerce module, language pack or theme is installed as a separate composer package. Each customization has its own Git repository. This means ultimate flexibility in the composition of the instances and has reliable Composer dependency management. For performance optimization, all packages are mirrored in a single private composer repository.
The monorepo GRA pattern
All development takes place in a single code repository. Automation generates packages for new versions and publishes them to a composer repository. The pattern combines the low development overhead of the bulk packages approach with the flexibility of the separate packages approach. The monorepo pattern is also ideal for running automated functional tests.
Choosing a GRA pattern
The choice for a GRA pattern is made by assessing the project complexity, the need for flexibility, and the development team’s ability to adapt.
Teams with little Adobe Commerce experience best start simple. However, if the project demands a more complex GRA pattern due to its characteristics, do not compromise.
Common project characteristics related to each pattern:
-
No GRA pattern: Single instance of Adobe Commerce without plans to extend. Multiple instances of Adobe Commerce with minimal commonality between them.
-
Split Git GRA pattern: Teams that wish to avoid Composer for their customizations, in most cases Bulk packages pattern is a preferred pattern to Split Git.
-
Bulk package GRA pattern: Customization codebase with high interdependency. Instances all have very similar combinations of custom packages. No frequent promotion or demotion of individual packages. Teams with little experience in code management and in need of simplicity.
-
Separate packages GRA pattern: Flexible release scope management needed. 50 or less custom packages are anticipated in the next 5 years. Potentially, global and regional layers of common code. No plans to migrate to a Monorepo pattern. The team is technically adept and has strict process adherence.
-
Monorepo GRA pattern: All characteristics of the Separate packages GRA pattern. More than 50 packages are anticipated in the next 5 years. Need for extensive automated testing. Support for ephemeral environments. Enterprise scale complex codebase that needs to scale without scaling maintenance cost at an equal rate.
The cost of a wrong choice
Migration from one pattern to another is possible. The diagram below shows the level of impact of moving from one pattern to another. Green lines show low impact, yellow and amber lines show moderately complex to complex migrations.
Commerce
- Commerce Tutorials
- Adobe Commerce Cloud
- Getting Started
- Global Reference Architecture
- Help and support
- Edge Delivery Services
- Webinars and events
- GraphQL and REST
- Adobe Developer App Builder
- Store Administration
- Customer Management
- Catalog Management
- Content Management
- Marketing Tools
- Orders and Fulfillment
- B2B for Adobe Commerce
- Tools and External services
- Commerce Intelligence
- Commerce Upgrades
- Back-end Development
- Native Front-end Luma Development
- Headless Architecture