Helix and Modular Architecture

Helix is Sitecore’ s code name for Modular Architecture, Helix is composed of 2 main areas:

• Principles
• Practical Applications (i.e. how we support/implement/conform to the principles/guidelines)

Unfortunately, many on slack & twitter are focusing on the Practical Applications and not the principles. The architectural principles are more important, than how we support/implement the website; So in this blog I will make a brief introduction to the principles.

Helix/Modular Architecture is primarily based on Packaging Principles. In addition, several concepts have been introduced to help support Packaging Principles:

1. Layers
2. Module (referred to a package in Packaging Principles)

Now whilst not strictly part of Modular Architecture – I believe all software development should adhere to SOLID principles.

Packaging principles

Is a way of grouping classes to make them more organized, manageable and maintainable! It helps us understand which classes can be packaged together which is called package (module) cohesion and how these packages should relate with one another called package (module) coupling.

“Building software without packaging, is like trying to build a sand castle one grain at a time” – Uncle Bob

The result of packaging in Helix terminology it is called a Module (not a package); therefore, for the remained of this blog I will use module i.e. Module Coupling/Cohesion etc.

Module Coupling

Module Coupling is the corner stone principle in Modular Architecture and determines how modules relate/depend on each other.

Stable-dependencies principle (SDP)

Depend in the direction of stability – a module should only rely on modules that are more stable than itself.

A stable piece of code is one where its interface does not change over time.

Features are expected to change over time and are less stable, as requirements change and or new requirements occur. Unstable code is not bad but a reality!

Stable-abstractions principle (SAP)

Abstractness should increase with stability. Modules that are maximally stable should be therefore maximally abstract. Unstable modules should be concrete. The abstraction of a module should be in proportion to its stability

Acyclic dependencies principle (ADP)

The dependencies between modules must not form cycles, i.e. no circular references are enforced by Visual Studio for C# but not JavaScript, Sitecore Templates, Query strings, web services etc.

Module Cohesion

The following principles help identify what should be packaged together as a module.

Common-closure principle (CCP)

The classes in a module should be closed together against the same kinds of change. A change that affects a module affects all the classes in that module and no other module.
What changes together, should live together.

Common-reuse principle (CRP)

When you depend on one class in a module you depend on all the classes in that module, not just the one you are using.

Reuse-release equivalence principle (REP)

Essentially means that the module must be created with reusable classes — “Either all the classes inside the module are reusable, or none of them are”. The classes must also be of the same family.

Layers

Layers help by visualizing and enforcing the stable dependency and stable abstraction principles of module coupling. Each layer defines the stability of the modules and the direction of dependency.

Modules in the feature layer should not reference each other. A layer is physically described in your solution by folders in the file system, solution folders in Visual Studio, folders in Sitecore along with namespaces in code.

A layer is physically described in your solution by folders in the file-system, solution folders in Visual Studio, folders in Sitecore along with namespaces in Foundation Layer (previously call framework).

Foundation Layer

This layer is the most stable and contains only modules which are not subject to change, and if they do change it will have implications for all modules, typical foundation modules:

• Taxonomy
• Dictionary
• Indexing

Feature Layer

Modules in this layer resembles the customer domain and need to be flexible, and therefore are more likely to change, typical feature modules:

• Navigation
• Search
• Metadata

Project Layer

The project is the least stable layer and can reference all modules as it is used to aggregate the functionality provided by the feature and foundation layers, typical project modules:

• Page Types
• Design
• Context (Responsible for dependency injection (IoC), of course a feature can internally use DI/IoC)

Module

The result of packaging a number of classes together is called a MODULE. Each module is represented by a single Visual Studio project.

A module divides domain functionality into loosely coupled modules with clear boundaries, where each Module can contain Presentation, Business logic, Sitecore Content (Templates, layouts, setting items, etc.) and Data (Sitecore, SQL, etc.).

I hope this blog post was helpful and I plan to do a series on common pitfalls which are usually related to the following 2 issues:

1. One or more modules needs to reference another module in the same layer (which they should NOT do).
2. how to identify a module and what should be in it.