The Sitecore Helix design principles exist for more than a year now and have caused quite some excitement in the Sitecore developer community. Here is a brief introduction of the principles, in case you are still missing out on it.
There is still some confusion about what Helix is and how it differs from Habitat. I want to take the opportunity to describe some key concepts of Helix and discriminate it from Habitat.
As the introduction states, Helix is a set of overall design principles and conventions for Sitecore development. The core message here is that it is not a product. Helix gives developers some architectural guidelines that emerged out of experience from past Sitecore implementations.
Habitat, in contrast, is an applied example of the Helix principles. It features a concrete solution based on the helix conventions, inlcuding preselected tools.
What Helix defines
Helix gives a multitude of guidelines, including Visual Studio solution structure, configuration & setting conventions, template structure and inheritance, multi-site setup, CI, and more. These guidelines are somewhat good practices that crystallized over a long period of Sitecore development, striving to avoid typical pitfalls of Sitecore implementations. There are too many helpful principles to go through all of them here, so I will focus only on the most relevant ones. I would highly recommend to go through the full Sitecore Helix Documentation.
Architecture Principles
A core focus of Helix is the seperation of functionality into Modules and their organization into Layers. Such an organization is beneficial because it reduces dependency between modules, hence minimizes side effects and additional effort in later iterations.
Conventions for structuring and naming
Helix defines some rules on how to organize the filesystem and items in the content tree. When you follow these rules, you can be sure that other developers can easily navigate your solution.
Configurations and settings
The terms configuration and setting are often used interchangeably and the resulting implementations often cause trouble due to that. Helix cleary destinguishes these terms and provides a table to simplify the decision process for you. Just follow the rules and you will automatically end up with a correct setup.
What Helix does not define
Helix does not define what tools to use. You can use your testrunner of choice, handle your content with TDS or Unicorn, do your builds with Bamboo, VSTS, Teamcity, or your CI tool of choice… Nearly all aspects of your development process can be chosen. As long as you stick to the basic concepts, you create a Helix-compatible solution.
A note on Habitat
Here is the takeaway message for Habitat: It is reference of just one way on how to implement based on Helix. You could build your own solution with completely different tools and still be in accordance with the Helix guidelines. If Habitat utilizes tools that are not used in your organization, that is not an argument against Helix architecture.
