Sitecore Helix Distilled

It seems like a lot of Sitecore developers struggle with Helix, finding it more of a hindrance than a benefit. Perhaps Sitecore have been too prescriptive in their documentation. Maybe the Habitat example site overwhelms people. Whatever the reasons, I don't think it needs to be that way.

If you distill Helix down to its essence, you'll find a collection of 6 architectural principles that were originally codified by Robert C Martin. They're known as the 'Principles of Package and Component Design' and they're not too difficult to grasp. That said, the language he uses can get pretty complex. So here's my attempt to translate the principles for new Helix developers.

Coupling

The first 3 principles focus on managing dependencies within your system. Broadly speaking, they help you decide which Helix layer your code should be added to.

Stable Foundation / Volatile Project

• Every Foundation module will probably have lots of dependent Feature/Project modules. As a result, changing a Foundation module might cause side effects throughout the system. So you better make sure your Foundation modules never need to change.
• Every time you add code to a Foundation module, ask yourself "Will I ever need to edit this file again?". If the answer is "yes", then you might need to rethink your approach.

The points above are derived from the 'Stable Dependencies Principle'.

Abstract Foundation / Concrete Project

• You can reduce the likelihood that a Foundation module will need to change by using dependency inversion techniques. 
• Abstract out the parts of your Foundation code that might be responsible for changes, by pushing it up in to Feature modules

The points above are derived from the 'Stable Abstractions Principle'.

Single Direction of Dependency

• You expect the Project layer to change frequently, and it should not be depended up on by any other layer
• Foundation modules should not depend on Feature or Project modules, because they are likely to change over time.
• Visual Studio prevents circular build dependencies, but think about ‘soft’ dependencies.Configuration files and Sitecore templates shouldn't reference anything outside of their associated module's scope.

The points above are derived from the 'Acyclic Dependencies Principle'.

Cohesion

The next 3 principles help you to determine what elements should and shouldn't be included in a Helix module.

Slim Modules

• A module should only contain things that its dependants need. If you could remove a element from a module without breaking dependent modules, then maybe it doesn't belong in there.
• Don’t force a Project module to depend on parts of a Feature module it doesn’t use
• Don’t force a Feature module to depend on parts of a Foundation module it doesn’t use

The points above are derived from the 'Common Reuse Principle'.

Complete Modules

• A module should aim to be self contained, so it should not force a dependant module to rely on other modules.
• A Feature module should contain everything a dependent Project module needs to complete a task. 
• A Foundation module should contain everything a dependent Feature module needs to complete a task. 

The points above are derived from the 'Reuse-Release Equivalence Principle'.

Enclosed Modules

• Elements within a module should be interdependent. If you could remove something from a module without breaking the module itself, then maybe it doesn't belong in there.
• The side effects of changing something in a module should be contained within that module.

The points above are derived from the 'Common Closure Principle'.


Of course, this post is a huge simplification and you really should try to absorb the principles in full. But it should at least get you thinking about the fundamentals.

Helix has a lot of rules and conventions to keep projects consistent, but they really don't mean much without a reasonable appreciation of the core principles. My advice to new Helix developers would be to get this important stuff nailed first. Worry about details like folder structures and project naming conventions later.