Sitecore Habitat and Helix

Sitecore Habitat is a demo site, built by Sitecore, to demonstrate the architectural approach to building a site using Sitecore Helix.  As best as I can tell, Habitat would be an ok starting place to start building a site, but the real interest is in the way the site was built and what that demonstrates.

One of the challenges of working in Sitecore is that every Sitecore partner and customer takes a different approach to working in Sitecore.  When moving from one partner to the other, the reality is that the approach to Sitecore is so different that the next partner is more than likely going to suggest that it is easier to re-implement it than to keep building on the current implementation.   As someone who has taken over a number of Sitecore implementations done by organizations who are newer to Sitecore, this is often the fastest way to start leveraging the higher level personalization and multi-variate testing of Sitecore or even to address performance or editing issues.

Wouldn’t it be great if there was an agreed upon standard out there for developing in Sitecore?  Something that came as “Sitecore Best Practice” and emphasized maintainability and flexibility of the system?   Sitecore Habitat demonstrates the thought behind Helix and shows a “real world” example of how that would work.

The architecture of Habitat is layered in the following way:

Habitat 3.PNG

The separation of these layers help to isolate the features in the Habitat solution.  The framework layer provides reusable generic ideas, not specific to the site.  The domain layer provide site-specific implementation, but does not address the specific content or design of the site.   The project layer deals with the specific design and content architecture for the site.

The different components further break down like this:

Habitat 2.PNG

Some of my favorite concepts in Habitat are:

Modular Architecture

At the Domain level, there is strong separation between the different modules, which focus on a very specific function, such as navigation.  The navigation has no dependencies on any of the other components at the domain level, only leveraging things in the framework layer.  To further decrease coupling of modules, the relationships between components should be dyanmic, like through an Inversion of Control (IoC) container.



Another common mistake in Sitecore sites is to develop the entire solution focusing on a single website, which may be the first goal of the project.  Over time though, the usage of Sitecore as an asset in the organization typically grows.  When the decision is made to expand to an intranet site, a microsite or another brand, we do not want to re-architect the site.

The helix approach focuses on the idea of Tennants and Sites.

  • Tennants – a grouping in the business that represents a collection of sites.  This may be brands or regions.  The content and sites related to a single tennant likely have no shared content or authors with another tennant.
  • Sites – websites, usually with their own domain name.  Content can be local to a page, shared at the site level or visible to all sites in a tennant.

The benefit of this type of content architecture approach is that the initial setup allows for Sitecore usage to grow over time without need for re-architecture.

If you want to learn more about the Habitat project, Thomas Eldblom has a couple of great videos on YouTube that walk through the architectural choices:

%d bloggers like this: