Software Architecture software-architecture
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.
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 https://maven.apache.org/developers/conventions/code.html. It is best to follow these conventions, as it will make it easier for new resources to come up to speed quickly.