Core Framework with Helix

A Framework is a concrete or conceptual platform that provides some generic functionality that can be overridden by developers or users as per the business requirements, thus providing application-specific code. It helps in the standardization of the development and deployment process to develop components that are universal and re-usable. A software framework is intended to simplify the project of development, thus allowing the developers to focus on project requirements rather than creating repetitive functions and libraries.

A core framework ensures:

• Standardization: The components built on a framework will follow all the conventions of the underlying framework resulting in a minimal deviation from best practices.
• Re-usability: A core framework ensures higher re-usability as all the components developed using the framework will be intended to work similarly.

 

A Framework has to follow certain principles and guidelines which will work well for the platform and considering the fact that Sitecore recommends Helix due to its Extensibility and Reusability, building a framework following Helix principles seems to be ideal. Sitecore Helix is a set of design principles and conventions for Sitecore development. It is aimed at optimizing the development by managing the system dependencies systematically to develop future proof implementations that are easy to maintain, scale, test and manage. Unlike a strict development rulebook, Helix governs the solution architecture to ensure extensibility and reusability.

 

Helix Principles - Overview

Helix follows Robert Martin’s “Principles of Package and Component Design” which provides a framework for module creation (cohesion) and module interaction (coupling) that help us obtain the fundamental goal of any object-oriented programming i.e. “high cohesion” and “low coupling”.

 

Typical Dependency

 

Dependencies in Helix

Module Cohesion

• The Reuse-Release Equivalence Principle

  All classes in a reusable module should be reusable by a similar audience.

• The Common-Reuse Principle

  Classes that are firmly bound to one another with class connections should be in a similar module.

• The Common-Closure Principle

  A change that influences a module influences every one of the classes in that module and no other module.

 

Module Coupling

• The Acyclic Dependencies Principle

  There should be no circular dependencies between modules.

• The Stable-Dependencies Principle

  Any module that is bound to changes should not be dependent on by a rigid module.

• The Stable-Abstractions Principle

  A stable module should be abstract so that it can be extended easily.

A Sitecore implementation/application can have several functionalities e.g. checkout, accounts etc. the code for these functionalities is separated into viable pieces known as modules. Modules are used to group objects that are dependent upon each other. These objects help shift the approach of application development from type-centric to feature-centric.

 

Designing a Layered Architecture with Helix

Layers in Helix Architecture are conventions that help define the dependency flow in the solution. These layers re-enforce the Stable-Dependencies and Stable-Abstraction principles defined above by:

• Defining the direction of dependencies à Foundation > Feature > Project
• Defining what a module should contain àModules at Foundation layer should be most stable and rigid.

 

Source: Helix

Helix Architecture conventions define three layers: Foundation, Feature, and Project. These layers have a clearly defined purpose and it is vital to understand the core principles behind this abstraction.

 

 

The Foundation Layer

As the name suggests, Foundation Layer forms the base for Feature and Project layers. Unlike Feature Layer, there are no strict restrictions on dependencies of modules. Modules can depend upon other modules of foundation layer until other coupling principles; Acyclic Dependencies i.e. there should not be a cyclic dependency between two modules and Stable Abstraction i.e. A stable module should be abstract so that it can be extended easily are followed.

Any technology framework utilized in the implementation ranging from jQuery to design patterns like Dependency Injection forms the base for a solution and shall be leveraged across different modules in Feature and Project Layers, forcing them to be structured within Foundation Layer. Sitecore’s Dependency Injection based on Microsoft Dependency Injection to implement IoC must be a good choice as it comes with high flexibility of mapping the dependencies through config entries.

This layer will also contain any module that enables connection to an External System that might be accessed by the modules in Feature Layer. An example of such a system would be a CRM Integration. CRM might be used by multiple modules at feature level like Products, Reviews etc. To accomplish this, we need to add this integration at Foundation Level so that same connection could be utilized by multiple modules. This also ensures we have no redundant code which makes upgrading and modifying the code much easier.

 

External System Integration

As per the Common-Closure Principle, modules of Feature Layer cannot be dependent upon each other. Hence, any common functionality that shall be utilized by more than one module including utilities, extensions etc. shall be identified within the Foundation Layer.

As a basic thumb rule, a module must go into Foundation Layer if the functioning of the entire solution gets hindered when that module is removed.

 

The Feature Layer

The Feature Layer contains all the concrete functionalities of the implementation. These might be divided based on the Business Owner’s understanding or the Business logic e.g. News, Search, Accounts etc. Each module in this layer must strictly conform to Common-Closure principle i.e. any change made to the module should not affect any other module. The modules also need to adhere to Principles of Package cohesion i.e. a module should not be dependent upon any other module of feature layer.

Feature modules are separated/grouped based on the functionality and each module shall comprise of multiple components required to achieve the functionality. For instance, the Alerts module shall contain all the code (Eg: Controller, Views, js etc.) that are specific to display alerts in the implementation.

There needs to be a clear understanding on the files to include in the Feature Layer. For instance, the Alerts Feature Module shall hold the js files required to display the alerts as it is specific to Feature, while the css styling for the same depends on the branding guidelines or theme of the entire site and it isn’t considered specific to Feature and expected to be placed within Foundation Layer.

As per “Common-Reuse” and “Common Closure Principle”, all modifications related to a module should live together. Because the TDS requires individual projects to be setup for every feature to conform to this principle, Unicorn is widely preferred to hold the Sitecore Items related to the feature within the specific feature module for better maintenance though TDS still works well.

It is highly important to analyse and opt the Design Pattern that will work well for specific Feature. Though Repository pattern is widely used with Helix and helps to ensure high testability of developed Feature modules, there are other Design Patterns including Factory Pattern, Singleton Pattern etc. which will work well for certain scenarios and need to be opted after quality analysis.

xUnit Framework is being widely opted as Unit Testing Framework while working with Helix considering the extensibility and flexibility. Sitecore Fakedb in conjunction with xUnit helps to run advanced test scenarios mocking the Sitecore Content Tree. This helps to ensure high level of testability to deliver quality code. Similar to Sitecore Items, Test projects are part of the module and hence required to reside together.

 

The Project Layer

The Project layer is a composition layer in which required features are aggregated. This layer provides a context in which the solution will be used. This can have multiple modules depending upon the multiple sites or tenants using the solution.

Components specific to a site resides within Project Module created for a site while Features are meant to be used across multiple sites as needed. Project Layer is expected to hold the Layout, any functionality that combines two or more features together and Configurations & Sitecore Items that are specific to a site (Eg: Page Templates, Settings etc.).

A Common Project Module which shall contain files that are intended to be shared across different sites (which cannot be placed within Feature Layer without breaking dependency flow), will help to ensure high level of scalability while adding more sites to the implementation.

Bundling and Minification of the js/css files are required to be configured at the Project Level to include the js and css files from Foundation and different Feature Modules as needed.

 

Helix Solution Structure

At Altudo, we help our clients deliver exceptional customer experiences through 1:1 personalization & enhanced engagement, to grow revenue streams.

As Sitecore Platinum implementation partners, our deep understanding of the Sitecore ecosystem goes beyond the basics of CMS, to unleash the true potential of a seamless, personalized website experiences & curating engagement analytics throughout the customer journey.