Sitecore Helix Workshop

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

Sitecore Helix & the 3 Layers Principle

Helix takes a focus on breaking down a website into :

• The project layer is the composer and brings it all together. This layer contains anything that is to do with pulling the site together. Page types and content types that bring the various features together to make up a page on the website.
• The feature layer is the where all the functions for the website are created. This is where you define your interface templates i.e. fields for content entry, your cshtml files, your controllers and models. Feature modules do not depend on other feature modules.
• The foundation layer is where the reusable functional code exists to support features. It doesn't contain views or renderings and does not refer to any feature or project modules. The dependencies of a foundation layer can include other foundation modules.

Modularity and Project Structure

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:

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.

Principles of Package Design

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

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

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.

Wrapping Up

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.

— Ben Norman