Sitecore Helix is an approach that all Sitecore developers need to keep in mind and be aware of in their daily work.

Sitecore Helix is characterised by three elements:

1. Layers

2. Coupling

3. Cohesion

Sitecore Helix is a collection of recommended practices and conventions for the solution architecture of Sitecore product implementations.

1. Layers

To help with the solution architecture, Sitecore Helix defines three layers:

• Foundation

• Feature

• Project

Modules are grouped into relevant layers. Lego is  good example of characterising Foundation, Feature and Project:

• A Lego park model (Project)

• The Lego package comes with a water fountain (Feature), trees and flowers (Feature), a public toilet (Feature), etc,

• A base board (Foundation)

• Lego bricks (Foundation of everything)

Modules in the Foundation layer are very solid. They are the most robust and will not easily break or need maintenance. From a hardware perspective CPU, Memory (RAM) are foundation modules of a computer. They are modular and reusable between compatible systems.

A Sitecore related example is the Dynamic Placeholder. It’s the foundation where the Sitecore Experience Accelerator (SXA) relies on.

Modules that add or extend the functionalities to the system are called Feature modules. They should be designed in a modular way and self-contained and don’t depend on other modules. For example, the trees from the Lego® project do not depend on the water fountain.

The project layer is where things get assembled and presented. The usage of layers happens in not only code, but also folder structures in the file system and in the Sitecore content tree.

2. Coupling

Coupling refers to how modules relate to each other, i.e. the dependencies between these modules. This enforces the dependency flow vertically:

The direction of the flow depends on the stability; the lower it is, the more stable. A module can only rely on what is more stable than itself. Anything can rely on (or reference) the foundation modules (even a foundation module itself) because they’re the most stable parts of a system.

A feature module can’t reference other feature modules. And a project, i.e. the final website or the completed Lego® model, consists of the various feature and foundation modules. The technique to try to separate the modules from each other is called de-coupling.

Sitecore Helix promotes Low Coupling, so the modular architecture can be easily achieved. This also enables the reusability of modules.

Low coupling doesn’t only apply to the code. Sitecore Helix encourages doing this from an Information Architecture (IA) perspective as well. For example, when designing templates, the method of composition should be favoured over inheritance.

Composition means having a template based on data templates that only contain the fields it needs. For example, a News page template would be based on the _SeoMetadata and _NewsContent data templates but not _EventContent.

3. Cohesion

Cohesion, as its name suggest, “sticks” something together. While Sitecore Helix promotes low coupling between the modules, it encourages High Cohesion within each module.

When a module has a single purpose, all its elements work together in order to produce the desired output. There shouldn’t be anything in the module where its effort is not to make this happen. The more closely these internal elements work together, the more cohesive it is.

Sitecore Helix also implies cohesion from the packaging perspective. For example, if two modules are related, they must be packaged together.

Benefits of Sitecore Helix

Applying the this architecture offers the following benefits:

• Cost reduction

• Reusability

• Low complexity

• Low maintenance

• Easy troubleshooting

• Productivity

Cost reduction

Following this principle means that web solutions are designed to be easily understood and extendible. Low coupling between the modules means that any new module can be developed regardless of what the others are doing or how they function. Introducing a new module or updating an existing one doesn’t require retesting the entire module set. Following the principle also reduces the project familiarisation time. Newcomers can easily follow the structure and find what they need, from code or IA.

Reusability

When modules are designed individually, it increases the opportunity for reusability. For example, you could reuse the Lego trees and flowers on a different project (a garden maybe) because it only depends on the (foundation) base board (grass or land). Similarly, a well-designed Sitecore module can be used on different sites in the solution, or in a totally different solution.

Low complexity

It may require some initial time to decide how the overall solution will be architected. However, once it’s done, what the team follows is a clear structure that’s easy to read and extend.

Low maintenance

As modules are developed with low coupling in mind, they rarely depend on each other. Everything contributes to the module’s functionalities are defined in the module itself. This includes code, presentation and IA. Developers can focus on the single module without worrying about its dependencies or the possibility of affecting other modules.

Easy troubleshooting

Troubleshooting is easy. When something doesn’t work, developers can easily identify what module it is and quickly find the relevant information from the well-defined architecture to resolve issues. Combined with proper logging, the turnaround time can be hugely reduced.

Productivity

Although this principle is not a standard from Sitecore, it can be made a standard throughout the team. Projects don’t work without the whole team following the same principle. Making all team members understand and adopt the Sitecore Helix principle, means the team works in a more efficient way by increasing productivity and shortening the time-to-market. The examples below demonstrate the following:

• Non-Helix architecture

• Helix architecture

Non-Helix architecture

This is a common N-Tier architecture for a website solution. The website depends on the Data Access Layer (DAL) and the Business Logic Layer (BLL) libraries (modules). In this example, the various modules in the BLL depends on each other, meaning they are tightly coupled.

While this architecture might work well, it exposes the following challenges:

• High maintenance cost: This is because of the dependencies between the BLL modules The Helpers module serves multiple purposes. It’s not guaranteed that changing it will not affect other modules.  In addition, if changing the Content Repository also implicitly changes something in the Helpers module, developers can’t guarantee that the News Repository will not get affected. Therefore, changing any of the modules in the BLL requires re-testing everything. This makes the solution harder to maintain.

• Hard to reuse and extend: Modules are hard to reuse and extend because they’re tightly coupled. Developers can’t simply take the News-related functionality away since it depends on the Helpers. When adding a new module, developers may be forced to rely on the Helpers module because it contains important methods to manipulate data.

• Difficult to troubleshoot: Architecture can make troubleshooting difficult. For example, if the page stops showing content, we cannot quickly know whether the issue came from

Sitecore Helix architecture

It reduces the challenges of a non-Helix approach by refactoring the architecture:

• The Data Provider module becomes more robust and efficient (assuming that it’s a wrapper of Sitecore’s native API)

• The Helpers module has been removed and relevant methods moved to the Content and News modules

• The Content and News module serve their own purposes and are reusable across the sites in the solution

• Because the modules no longer interfere with each other, the solution incurs lower maintenance costs

• Upgrading, fixing or adding modules doesn’t need re-testing on other modules

• Easy to troubleshoot, as the modules are now self-contained

• Easy to package because modules are in their own folder, their own file system as well as in IA

• A better architecture that’s easy to follow and extend

These principles are continually being used on larger and more complex Sitecore projects. For example the Sitecore Experience Accelerator (SXA) and Sitecore Experience Commerce, as well as many community-driven modules.

Read the full Helix documentation where it details every aspect developers need to be aware of.

Working with Codehouse

At Codehouse we’ve used the Helix architecture on many Sitecore projects and were one of the first Sitecore partners to launch a Sitecore website built on the architecture.

If you have a Sitecore project in the pipeline, get in touch.