Last month we were invited to the Sitecore Helix Workshop presented by James Hirka from Sitecore to take a look at both the theory and practical exercises demonstrating the Principles of Helix. During the workshops there were some great examples and documentation that we've summarised below.
The reference web site that we worked with can be found at http://helix.sitecore.net and the practical part of the workshop was an exercise extending a well known example of a Helix implementation called Habitat, available for download at http://github.com/Sitecore/Habitat.
Several extension exercises talked directly to the theory which and can be found at https://github.com/Sitecore/Sitecore.Demo.Group
Helix takes a focus on breaking down a website into :
One of the big take-aways was that reuse is not the primary goal but rather a very favourable side effect. The primary purpose of the way you can break down a website with Helix is understanding, predictability and maintainability.
All the concrete elements of your feature are stored together in a single Visual Studio Project.
Commonly when you talk to internal or external customer, your mind is racing to see the best way to deliver what is being asked for. Questions about where you've written that code before come up and if you have to put this feature into an existing project, how messy is going to be? If you keep all the elements for a feature separated in a feature then the chances of finding the right place for your code and not adversely affecting existing code is increased. Happy days!
Using the source code repository root as the base directory, here is a potential side by side comparison of a conversation between you and the customer:
|Customer (Internal or External)
|Can I have a new website called "My Great Recipes"
|Create a VS Project at
|I would like a blog on that
|Create a VS Project at
|The website needs a full text search on it and the blog should also have its own searching
|Create the following VS Projects
/src/Feature/Search/src/Foundation/IndexingAdd a few extra cshtml files to /src/Feature/Blog
|The users should be able to identify my site easily and I want to have my logo in the top left
|Can we make the site pink and green
|I really want to use Sitecore
Each of the Features of a website can be estimated and developed in parallel or sequentially more easily. The way you break the project up in Visual Studio marries up to the way you discuss the website. For example, the client says to you, we would like an events page (Feature). You imagine yourself creating a new Visual Studio Project called events in the feature layer. Then you remember, you did that for the last project and you can easily say "No worries, we can do that". The conversations along with the code are simplified and more predictable because the boundaries of each Feature are better understood by all concerned. Imagine if the client can talk the same language as a developer. Anyone for a Mojito? Work becomes a great mix of sweetness and fun.
Helix is based on widely accepted principles known as the Principles of Package Design. These came from "Uncle Bob" and discussed in the same book as SOLID. Here is a link to help you find the book.
Principles of Package Cohesion helps define the granularity of modules and helps define abstract and concrete modules. There are 3 main principles that are applied for Package Cohesion.
The Reuse-Release Equivalence Principle
The granule of reuse is the granule of release.
The Common-Reuse Principle
The classes in a module are reused together. If you reuse one of the classes in a module you reuse them all.
The Common-Closure Principle
The classes in a module should be closed together against the same kinds of changes.
Principles of Package Coupling helps stabilise an implementation. It defines the direction of dependencies which simplifies and therefor stabilises an implementation. There are 3 main principles that are applied for Package Coupling.
The Acyclic-Dependencies Principle
Allow no cycles in the module dependency graph.
The Stable-Dependencies Principle
Depend in the direction of stability.
The Stable-Abstractions Principle
A module should be as abstract as it is stable.
We're excited about the possibilities that Helix presents to Switch and our customers. We're also enjoying adding some extra skills to our already comprehensive Sitecore expertise.
Subscribe for the latest news and events from our talented team and community network.