What are Helix and Habitat?

I thought I’d write a little bit about Sitecore’s “Helix” principles and “Habitat” demo implementation. After having a read through the documentation and having a play with some examples, this is my take on what defines both Helix and Habitat, and where one ends and the other begins....

Sitecore’s documentation defines Helix as “a set of overall design principles and conventions for Sitecore development” and Habitat as “a real Sitecore project implemented on the Sitecore Experience Platform using Helix” (the Habitat source code and setup details can be found at http://github.com/sitecore/habitat.) In short, Sitecore are now giving more concrete recommendations on how to develop and deploy solutions based upon their products - previously this was left to the discretion/wisdom of the implementation partner and their developers! As Habitat is an example of Helix principles, and I find it easiest to consider an example of something before considering its principles, I’ll discuss Habitat first. But even before that, let’s look at the pre-Helix/Habitat age …

How do people currently develop and deploy Sitecore installations?

Sitecore never used to make many strong recommendations in this respect - for instance, see here. Your mileage may vary, but based on recent Sitecore MVC implementations I’ve worked on, your development/deployment setup may be something like:

  • Development is done inside of the web root, alongside the Sitecore platform files
  • Code-wise - maybe you’re lucky and your solution follows a DDD approach. Typically this would mean separate layers/Visual Studio projects for
    • Presentation layer (usually this just means Views, CSS, JS in the web project)
    • An Application project/layer - this contains the code for an application’s features, which usually involves talking to the Domain layer. Your MVC controllers (which are referenced by Sitecore controller renderings) will probably make a call into this layer
    • A Domain project/layer - this code purely contains rules and knowledge concerning the relevant business domain (it’s a reflection of the Domain Model), which exists outside of the Application layer - the Domain layer has no knowledge of how the application is ultimately going to use the Domain Model to create useful features
    • An Infrastructure project/layer (contains repositories which serve up domain entities and code which mediates between the application and other external systems - think databases, configuration, REST APIs etc)
    • Other projects/layers which contain tests
    • Unicorn configuration or TDS projects which serialize the relevant Sitecore data from all across the solution (maybe these are split up into e.g. all Master and all Core items)
  • Most people know to patch Sitecore config changes in (rather than modify the config files which Sitecore provide) in order to make maintenance and Sitecore upgrades more manageable, but strategies for breaking up your "include" config into multiple files may vary
  • Various ways to build, package up and deploy the application: this will vary by implementation partner
  • Looking at the Information Architecture, there is usually not any consistent logical layering which applies within each of the folders for templates, renderings, datasource items, etc. Maybe you create subfolders (under templates, renderings, etc) for each Sitecore site, and then - if you’re really organised - further subfolders by application feature area. Perhaps you have some separation between “content”-type templates and “settings”-type templates


Habitat is a fairly “brochureware-y” demo website built using Sitecore - in fact you can see it for yourself now at http://habitat.demo.sitecore.net/. What are the core unique facets of the way that this application is developed and implemented?

  • All code/data/config sits in one of three layers, which are pervasive across the application implementation. “Modules” are groups of functionality within all of the layers
    • Project: this layer is at the top, and can mainly be thought of the place where you compose content templates for a particular Sitecore site - for instance, the page templates which are available for a particular site live in a “Project” templates folder - and are composed entirely of “Feature” layer templates (and as such the features are decoupled from the Sitecore site)
    • Feature: in most cases you can think of a feature module as a self contained piece of application functionality - usually this consists of a Sitecore template (which will ultimately end up defining part of a page, or a datasource item - by being referenced by a Project layer template), a Sitecore controller rendering, an MVC controller and associated code, and any relevant configuration. Feature modules may depend on Foundation modules
    • Foundation: these modules typically contain things which need to be shared across the implementation (and even across multiple implementations) - logic concerning things like indexing, shared utility code, JS frameworks etc

These layers are evident in the file system, and in the Sitecore tree the templates and renderings are also split up into folders reflecting each of the three layers

  • Most strikingly, each module within a layer is set up as a separate Visual Studio project. So for instance, the Navigation feature lives within its own project, with its own unicorn configuration, code, views, and configuration files. The feature is entirely self-contained (notwithstanding any dependencies on Foundation level modules)
  • Build scripts enable deployment packages to be built from multiple solutions/repositories, for instance, selecting a subset of available features to deploy
  • Development happens outside of the web root

Here are a few examples of how the Project/Feature/Foundation split looks in Habitat:

  • Markup specific to a feature lives in the Feature layer, as this is feature-specific; site-wide styles and dynamic view binding configuration (placeholders) live in the Project layer, as these are site-specific
  • JS used predominantly for site-wide styling lives in the Project layer, whereas functional scripts (with behaviour tied into a specific feature) live in the Feature layer. Layouts (i.e. “page” html - head, body tags etc) live in the Project layer
  • Each site’s content and the templates on which the content is based (page and datasource templates) are part of the Project layer
  • Global frameworks (Bootstrap, jQuery) are part of the Foundation layer
  • Any site-specific data is serialized into the relevant Project module, plus the relevant system/languages items for that site
  • Security - Habitat defines a “functional” user role for each feature module (this might seem a little onerous, but experience shows that it can be difficult to retrofit security considerations after the initial “requirements” stage - so if your client requires fairly granular security, perhaps ask them upfront which roles should have access to which features, and implement the role and security settings along with the feature.)

In addition, Habitat comes with some functionality to reinforce the principles on which it is set up and maintained - which you can easily reuse. A few examples are:

  • A “getRenderingDatasource” override to allow the Datasource Location and Datasource Template to vary per project (both of these targets will typically be part of the Project layer) with a convention based approach - enables renderings (living in the Feature layer) to not depend on the project layer.
  • A Foundation dictionary module is provided which:
    • Enables the dictionary root item to be set at the site level in Sitecore (the path is defined in the <site> config node) - supports the principle of feature reuse, as different dictionary text can be set per site feature instance without having to alter the feature implementation
    • Provides some HTML helper extensions which ensure that the Experience Editor is supported for dictionary text
  • Some Gulp build scripting to help streamline your development process


Taking a step back, let's try and summarise what Helix principles are, trying not to reference the Habitat example too much (although this is a little tricky!)

  • In line with most modern software literature, Helix advises prioritising low coupling over reusability/removal of duplication
  • The key to this is the Project/Feature/Foundation module/layer division
  • Plus 'extreme' modularisation - in Habitat this manifests most obviously as a large number of Visual Studio projects
  • Module re-use across solutions is encouraged. There’s not necessarily a 1:1 mapping between a solution and a Sitecore deployment instance
  • A “feature-oriented” approach which ruthlessly divides up functionality to reflect units of business value, rather than portioning up code and data from a more developer-oriented perspective. For instance, in Feature modules, related data/code/presentation are kept grouped in the same module - which somewhat flies in the face of more traditional layering/separation wisdom
  • Bind everything dynamically where possible, to increase reusability
  • Helix also attempts to standardise some of the terminology which may not be used consistently by Sitecore developers - for instance, the concepts of Content Items (editor controlled and owned) and Definition Items (developer controlled and owned)
  • Helix also promotes the use of partitioning of Sitecore data by “tenant” - where the definition of a “tenant” is kind of one level higher than a Sitecore “site” - i.e. one tenant may “contain” many sites. The purpose of a tenant grouping is to allow sites within the group to share certain features across the sites. See here for a bit more about tenants (in the context of the Sitecore Experience Accelerator product.)

Some concrete implications of a Helix approach might include:

  • You may wish to aim for Feature modules with no significant Foundation dependencies, to maximise reuse (probably this is only achievable for “brochureware”-type marketing features, without much knowledge of the business domain)
  • Compatible renderings - these must now live within the same Feature module to be deemed compatible. Or vice-versa - if renderings are compatible (they accept the same datasource template), you know that they should be grouped together in the same Feature module

The overriding purposes of the Helix principles are, in general, geared towards helping people implement Sitecore solutions using modern maintainable standards. A lot of this is achieved by driving a “feature” rather than “type” mindset in the way code and data is modularised. In addition to this benefit, this are a few other benefits of Helix which are more specific to Sitecore:

  • To make upgrading easier
  • Having a suggested approach to solution setup makes it easier for teams which are new to Sitecore
  • Having a consistent approach to solution setup makes it easier for when Sitecore Support need to get involved with investigating any issues with your implementation

To really get a feel for what Sitecore are trying to achieve, there’s no better way than setting up the Habitat site for yourself (http://github.com/sitecore/habitat) and reading through the official documentation (http://helix.sitecore.net). I’ll be soon following up this somewhat objective post with another article which looks more critically at Helix and Habitat!