Software Architecture software-architecture

AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.

Design for upgrades design-for-upgrades

When extending OOTB behaviors, it is important to keep upgrades in mind. Always apply customizations in the /apps directory and either overlay on top of the corresponding nodes in the /libs directory or use sling:resourceSuperType to extend the out of the box behavior. While some modifications may be needed to support a new AEM version, the new version should not overwrite your customizations if this practice is followed.

Reuse template and components when possible reuse-template-and-components-when-possible

This will allow for the site to maintain a more consistent look and feel and simplify code maintenance. When a new template is needed, make sure to extend from a shared base template so that global requirements such as clientlib inclusion can be coded in one place. When a new component is needed, look for opportunities to extend from an existing component.

Design template designs design-template-designs

By defining which components can be included in each parsys on the page, the consistency of the look/feel of the site can be controlled. By restricting access to the design on pages, “super authors” can be allowed to modify the allowed components per page without developer intervention while ensuring that the other authors follow the corporate standards.

Develop a SOLID architecture develop-a-solid-architecture

SOLID is an acronym describing five architectural principles that should be adhered to:

  • S ingle Responsibility Principle - each module, class, method, etc, should only have one responsibility.
  • O pen/Closed Principle - modules should be open for extension and closed for modification.
  • L iskov Substitution Principle - types should be replaceable by their subtypes.
  • I nterface Segregation Principle - no client should be forced to depend on methods that it does not use.
  • D ependency Inversion Principle - High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Striving for compliance with these five principles should result in a system that has a strict separation of concerns.

SOLID is a commonly-used concept in object-oriented programming and each element is widely discussed in industry literature.
This is just a short summary presented for awareness and you are encouraged to familiarize yourself with these concepts in more depth.

Follow the Robustness Principle follow-the-robustness-principle

The Robustness Principle states that we should be conservative in what we send, but be liberal in what we accept. In other words, when sending messages to a third party, we should completely conform to specifications, but when receiving messages from a third-party, we should accept non-conforming messages as long as the meaning of the message is clear.

Implement spikes in their own modules implement-spikes-in-their-own-modules

Spikes and test code are an integral part of any Agile software implementation, but we want to make sure that they don’t make their way into our production code base without the appropriate level of oversight. As a result, it is recommended to create spikes in their own module.

Implement data migration scripts in their own module implement-data-migration-scripts-in-their-own-module

Data migration scripts, while production code, are usually only run once at the initial launch of a site. Therefore, as soon as the site is live, this becomes dead code. In order to ensure that we don’t build implementation code that depends on the migration scripts, they should be implemented in their own module. This also allows us to remove and retire this code immediately after launch, eliminating dead code from the system.

Follow published Maven conventions in POM files follow-published-maven-conventions-in-pom-files

Apache has published style conventions at It is best to follow these conventions, as it will make it easier for new resources to come up to speed quickly.