Sitecore : Helix and Habitat

Note !!! I have moved my blog to https://pramisoni.wordpress.com/ . Please Visit https://pramisoni.wordpress.com/ for old and new posts.

From the last couple of days, I was reading about Sitecore Helix  Principles .

While reading into detail I thought to write a small article which summarizes the agenda of Helix Principle . This small Article may be useful for them who is already working in Sitecore and working on Component-based structure . Most of the contents have been taken from original site Helix  Principles.

Helix is a set of overall design principles and conventions for Sitecore development.

Here helix is talking about lots of design principles which you will come across when read the post

• Single Responsibility Principle
• Common Closure Principle
• Stable Abstractions Principle

Few more common terms which you will come across multiple time

• Component-based Architecture
• High Cohesion and Low Coupling

Helix focus on listed design principles that should be used during software or project development . This principle mainly focus on reduced dependencies between software modules.How modules should be structured and how individual sites should use these modules . Helix is a set of recommendations for making your Sitecore project as easy to create, test, extend and maintain as possible.

So if Helix is a set of recommended overall design principles what is habitat ?

Habitat is a real Sitecore project implemented on the Sitecore Experience Platform using Helix

Habitat is a Sitecore solution example built on a modular architecture. The architecture and methodology focuses on:

• Simplicity - A consistent and discoverable architecture
• Flexibility - Change and add quickly and without worry
• Extensibility - Simply add new features without steep learning curve

There are three main topics important to Helix and modular architecture:

Dependencies

which describe how feature and functionality in the solution relate to each other.

Layers

which control the direction of dependencies and thereby assure a manageable solution.

Modules

which define the isolation of features and functionality leading to greater discoverability and simplicity in the development process.

Helix describes the overall architecture of your Sitecore solution and thus communicates some guidelines and conventions which should be durable and flexible enough to be applied to any Sitecore project or business. The architecture pattern described by Helix is often referred to as Component-based Architecture or Modular Architecture.

The architecture principles and conventions defined in Helix focus largely on macro architecture, i.e. how the complete solution is put together for maximum productivity, quality and longevity.

Helix focus on High Cohesion and Low Coupling

1. Dependencies

This is both important in the micro architecture – how you break down functionality into methods, classes, class inheritance to Controlling dependencies throughout a solution

One of the fundamental principles of object-oriented programming is High Cohesion and Low Coupling. High cohesion relies on breaking the solution down into the right parts with logic that belong together – in Helix referred to as modules – and low coupling relies on keeping the number of dependencies between the different parts down to the absolute minimum.

2. Layers  

 2.1 Project Layer

 2.2 Feature Layer

 2.3 Foundation Layer

The layer concept in Helix supports the architecture by making the dependency flow completely clear everywhere in the solution

Layers helps control the direction of dependencies – the importance of which is described by the Stable Dependencies Principle or SDP, which is one of the cornerstone principles in Modular Architecture:

This principle tells us that a module should only depend on a module that is more stable than itself. If dependencies are not controlled, then you can end up in a situation where a change will unintentionally affect seemingly unrelated parts of the solution

The Sitecore Architecture Conventions defines three layers: Project, Feature and Foundation. Each layer have a very clearly defined purpose. In order to structure your Sitecore implementation properly, it is important to understand the principles behind each of these.

The three layers are defined in Visual Studio as Solution folders, in the file system and directories and in Sitecore as corresponding content type folders.

These are the typical places where layer folders are defined in Sitecore:

• Master:/sitecore/system/Settings/[Project|Feature|Foundation]
• Master:/sitecore/templates/[Project|Feature|Foundation]
• Master:/sitecore/templates/branches/[Project|Feature|Foundation]
• Master:/sitecore/layout/renderings/[Project|Feature|Foundation]
• Master:/sitecore/layout/layouts/[Project|Feature|Foundation]
• Master:/sitecore/layout/placeholder settings/[Project|Feature|Foundation]
• Master:/sitecore/layout/models/[Project|Feature|Foundation]
• Core:/sitecore/templates/[Project|Feature|Foundation]

2.1 Project Layer

The Project layer provides the context of the solution. This means the actual cohesive website, such as the page types, layout and graphical design.

The Project layer is typically small and contains few modules,

In Habitat there are two modules in the Project layer: Habitat and Common. Habitat represents the actual Habitat website, and therefore connects the features and page layouts in a way that fits the requirements for this website. The Common module paves the way for a multi-tenant implementation by defining some of the shared templates and settings between tenants

2.2 Feature Layer

The Feature layer contains concrete features of the solution as understood by the business owners and editors of the solution, for example news, articles, promotions, website search etc.

Each Feature layer module has to strictly conform to the Common Closure Principle.

This principle ensures that changes in one feature do not cause changes anywhere else, and that features can be added, modified and removed without impacting other features.

2.3 Foundation Layer

The lowest level layer in Helix is the Foundation layer, which as the name suggests forms the foundation of your solution. When a change occurs in one of these modules it can impact many other modules in the solution. This mean that these modules should be the most stable in your solution in term of the Stable Dependencies Principle.

Conceptually, it is helpful to think of all the frameworks and software you rely on in your solution as foundation modules. This includes the Sitecore platform, .NET and other technology frameworks such as Bootstrap, Foundation, jQuery etc. In the context of your implementation, these are typically very stable modules but when they do change.

A single Sitecore implementation can end up consisting of a large number of modules and this can lead to technical management issues.

Good rules of thumb are that your architecture should always have higher priority than any tools .

Each module has the following structure:

Module Name  

code          

serialization {Contains the serialized data from Sitecore}
Tests         {Unit or other test types for the module}

Modules

The concept of modules in Helix is derived from the concept of components in Component-based Architecture

Keep in mind that in Helix, modules are business-centric. This means that they should relate to business objectives and group together multiple technology entities that refer to this objective

For this reason, the breakdown and naming of modules can be one of the most challenging parts of adopting Helix

Helix force “The Single Responsibility Principle “ should always have higher priority than any management or tools related issues

Ex : Feature/Accounts : This feature handles everything involving user accounts: login, registration, xDB integration, user profiles, etc.

But modules are always grouped by their logical connection to a module – and never by type.

Helix principle force to Common Closure Principle(“what changes together should live together”) , we need not only to make it obvious which items in Sitecore belong to which modules, but also to manage and version the items alongside the code in these modules. But interesting thing to be noticed here helix only force to keep sitecore related ( Template , Item , Rendering ) and correct code as one module or group in Visual studio  but at same time helix follow conventional approach to  manage sitecore items .

• /sitecore/templates/[Project|Feature|Foundation]/[Module]
• /sitecore/system/Settings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/renderings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/layouts/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/placeholder settings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/models/[Project|Feature|Foundation]/[Module]

Helix use unicorn for serializing items

So here helix is talking lot about separation of module so what about  inheritance concept which we do when we create a base template and inherit this template to other templates without concerning which module that pages type is going to be used .

The architecture does not have the concept of a single common base template across all templates – which is a practice that is commonly discouraged as it will often lead to bloated items with unnecessary fields ( Helix concept believes) .

Multi-site and multi-tenant

Tenants are groupings in the business organisation that need freedom and autonomy to define and manage their own sites, channels and data.For example, this could be multiple departments in an organisation with separate websites, but a willingness to collectively define and share the features available on these sites in order to reduce the cost of development and maintenance.

Although Sitecore offers a great platform to support multi-tenancy in the software, there is no predefined tenant context in Sitecore.This means that the borders between what is shared between tenants and what can be defined autonomously is largely for you and the business to define. This includes content hierarchies, content repositories, media, workflows and more.

It is recommended that each tenant in a Helix compliant implementation has its own project layer module, i.e. that each tenant has the freedom to define its own set of datasource and page type templates (see Template types) as well as its own overall page layouts and sub layouts. If multiple tenants share templates or layouts, it is recommended to have a shared project layer module to host these entities. This gives the flexibility for a tenant to use shared as well as specific page types and layouts in their site or sites.

For know more details about tenant

The Habitat example site implements the Foundation/Multisite module that defines multi-site and multi-tenancy specific functionality for the feature modules

 

Front-end technologies

The front-end technologies used in the Habitat example site are introduced in the Foundation/Theming module and can therefore be shared across to all foundation, feature and project layer modules.The main front-end technologies introduced in Habitat are Bootstrap, jQuery, Bower and Sass. Furthermore,The theming in the Habitat example site is primarily based on Bootstrap. The module Foundation/Theming implements the base CSS theme based on an Atomic Design approach.

For detail Article check Helix Official Guide