Helix: Your Best Practice Guide to Sitecore Development
I like Sitecore. No, I love Sitecore. It is one of the most dynamic and configurable Content Management Systems on the market. If a client can envision something, I am confident that I can develop it in Sitecore.
But there is a drawback. With Sitecore being so open, it allows developers to approach a Sitecore development ecosystem in many different ways. For a long time, there have been many arguments on what is the best approach to Sitecore, that will allow rapid, reusable, maintainable, and proper SOLID development.
Well, Sitecore has done us a solid (pun intended). They have released Helix, a guide to development in Sitecore.
Helix is a set of overall design principles and conventions for Sitecore development.
And as a complement to Helix, there is Habitat. Habitat is a fully functional Visual Studio project, designed with the guidance of Helix. It has been said before, but it should be said again: use Habitat as a guideline for development, but DO NOT use it in production. It is not an accelerator!
Habitat is a real Sitecore project, implemented on the Sitecore Experience Platform using Helix. It is an example that allows developers to see how Helix is applied, and lets developers experience a project based on these principles. It also provides an excellent basis on which to develop additional modules, and extend existing ones.
One of the key tenants of Helix is layers. The layers are Project, Feature, and Foundation. The best way I have found to understand the layers is to think about Sitecore in a Multisite environment, where you have shared functionality, as well as site-specific functionality.
The Project layer is specific to a single instance of a site in your multisite implementation. The layouts, renderings, templates, and settings for the site would go in a Project. But these are only assets that are not shared among all sites; shared assets are in a different layer.
The Project layer provides the context of the solution. This means the actual cohesive website or channel output from the implementation, such as the page types, layout and graphical design. It is on this layer that all the features of the solution are stitched together into a cohesive solution that fits the requirements.
The Feature layer contains all of the features for the client solution. This is shared functionality that is used by all the tenants of the solution.
Each feature should be an organization of a business requirement and not of functional requirements. An example is site navigation. The feature should be
Navigation, containing all navigations and variations for the site, not a feature called
It is important to note that each feature project should contain all necessary Sitecore items, controllers, views, and code that is needed to make it run. Like the Common Closure Principle states, "Classes that change together, are packaged together.' So everything your feature needs should be packaged in the feature, not scattered through the solution.
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.
The features are expressed as seen in the business domain of the solution and not by technology, which means that the responsibility of a Feature layer module is defined by the intent of the module as seen by a business user and not by the underlying technology. Therefore the module’s responsibility and naming should never be decided by specific technologies but rather by the module’s business value or business responsibility.
The Foundation layer contains what the name says. It is all the base features that make up the core of the solution. It is where shared libraries, sitecore items, and base renderings are located. Features should not have dependancies to other features, they should only have dependancies to the 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 means that these modules should be the most stable in your solution in terms of the Stable Dependencies Principle.
The quickest way to get started is to download Habitat, and start to understand the architecture. It is a fully functional solution that you can build, deploy, and change. But again do not use it as an accelerator.
If you are starting from scratch, I found a good Yoeman generator called generator-prodigious-helix that will help build out the Visual Studio scaffolding. It currently supports TDS, but I am hoping to assist and add Unicorn generators to the project.