5. COPYRIGHT 2017
HELIX INTRODUCTION
COPYRIGHT 2017
What is Helix?
âHelix is a set of overall design principles and conventions for Sitecore
development.â
Principles
Tells you why
Tools
Guides you
Conventions
Tells you how
Examples
Shows you
9. COPYRIGHT 2017
FOUNDATION LAYER
COPYRIGHT 2017
Foundation Layer
ď§ Most stable layer in the solution
ď§ Interactions with third party libraries.
ď§ Can contain Solution-specific business logic available to multiple features
ď§ No solution-specific presentation elements. (no Views)
ď§ One foundation module can depend on another foundation module. But be
ware of Acyclic Dependencies Principle
10. COPYRIGHT 2017
FEATURE LAYER
COPYRIGHT 2017
Feature Layer
ď§ Contains concrete features of the solution as understood by the business
owners
ď§ Ex: news, articles, website search
ď§ Expressed as seen in the business domain of the solution and not by
technology
ď§ Ensures that changes in one feature do not cause changes anywhere else.
ď§ One Feature module must never depend on another Feature module
11. COPYRIGHT 2017
PROJECT LAYER
COPYRIGHT 2017
Project Layer
ď§ The Project layer provides the context of the solution
ď§ Stitches together all of the features into a cohesive solution
ď§ Brings together the concrete graphical design
12. COPYRIGHT 2017
TEMPLATE TYPES
COPYRIGHT 2017
Templates Types
Template Type Can have a page layout? Exists in which layers
Interface template No Feature or Foundation
Page Type template Yes Project
Datasource template No Project
Settings template No Feature or Foundation
Folder template No All
Rendering Parameter Template No Feature or Foundation
14. COPYRIGHT 2017
SITECORE HABITAT
COPYRIGHT 2017
Sitecore Habitat
ď§ Habitat is a 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.
1. Depend in the direction of stability.
2. There should be no circular dependencies between packages.
3. A module should be as abstract as it is stable.
4. A change that effects a module affects all the classes in that package and no other module.
5. Classes which are tightly bound to each other with class relationships should be in the same module
6. Either all of the classes in a module should be reusable or none of them are.