Helix is a set of design principles and conventions for Sitecore development.
So why I need Helix guidelines?
Whenever you develop any application or system, you need to follow some guidelines in order to ensure compliance with various essential parameters. So for example scalability, efficiency etc.
Helix provides set of guidelines for developing Sitecore solutions in order to improve efficiency, effectiveness, reducing costs, and time to go to market.
What are the benefits of Helix guidelines?
Sitecore provides Habitat which is a Sitecore project developed using Helix principles. Habitat provides lots of pre-built and tested set of common modules.
So developing Sitecore solutions using Helix will have following advantages.
Shorter Learning Curve
People who are familiar with the Helix principles/conventions or the Habitat example will be able to work more easily on other convention-based projects with minimal training. So learning curve will be reduced for moving team members from one project to another one.
Better Sitecore Product Support
Sitecore will be able to provide better product support to projects built using the Helix conventions, enabling them to resolve issues more quickly. Currently, whenever we ask for support, it takes the time to get support from Sitecore team as they have to reproduce environment.
More reliable solutions
If we develop projects using Helix principles which will make it compatible with Sitecore conventions. This, in turn, will make the project more reliable as these principles are well thought and all the modules are well tested.
Easy upgrade process
As we develop a Sitecore solution using recommended conventions, Sitecore will be able to provide better guidance on how to update and upgrade existing Sitecore projects when new versions and new products are released.
Less time to go to market and reduced cost
Habitat provides well tested pre-built components which can be consumed to develop Sitecore solutions and so reduced time.
How do you start on this?
First, you need to understand the terminology for Helix conventions. If you are developing Sitecore solutions for some time, you will understand these terms but the scope for some familiar terms are expanded. So let us take an example of Assets definition which is as follows:
Technically an Asset refers to a digital asset such as images, but can also mean the actual output from any process or task in your entire application lifecycle: code, files, visual design, data, content, configuration changes, deployment packages etc.
You can find the definitions at http://helix.sitecore.net/introduction/definitions.html
What are the important aspects of Helix Architecture?
Helix is often referred to as Component-based Architecture or Modular Architecture.
Sitecore uses this architecture approach for some good benefits like reusability and rapid development, but as per Sitecore, core motivators behind the conventions are simplicity, flexibility, and extensibility in the implementation.
We need to understand three basic aspects of Helix and modular architecture:
Logical architecture of Helix
Image Source: http://helix.sitecore.net
Dependencies which describe how feature and functionality in the solution are coupled.
It is always highly recommendable to have High Cohesion and Low Coupling between features.
Not Recommended Practice (Uncontrolled Dependencies, High Coupling)
Image Source: http://helix.sitecore.net/
Recommended Practice (Controlled Dependencies, Low Coupling)
Image Source: http://helix.sitecore.net/
Layers which control the direction of dependencies and thereby assure a manageable solution.
The layer concept is to provide dependency flow completely clear everywhere in the solution, in Sitecore, in Visual Studio and even in the file system.
Additionally, the layers provide a structure that helps in maintaining the project for the long term.
Image Source: http://helix.sitecore.net/
Modules – To decouple the features/functionalities. This provides ease in the development process. In Helix, modules are business-centric.
These are examples of modules in the Habitat example site:
Feature/Accounts
This feature handles everything involving user accounts: login, registration, xDB integration, user profiles, etc.
Feature/Navigation
All elements of navigation on the website are handled by this module. This includes primary and secondary menus, breadcrumbs and link lists.
Domain Language
This is another very important aspect. Domain language is to decide terminology and naming between developers and business users. The development team should remember that true users of the code are business users and not the developers or technical project members. So it is very important to choose the term very wisely so that it can be understood by everyone.
Solution Structure
All the conceptual modes should be grouped logically and not by VS projects so all Visual Studio projects belonging to a logical module should be managed together in one VS solution.
Following is the example from Habitat project.
Image Source: Habitat project
Solution Structure
Each solution to have “Feature”, “Foundation”, “Project” for each module. You can then group these modules into their own solutions. You can have more folder in addition to above but they will not act as layers.
All of above is to make features easily discoverable, and so they all should be in layers.
Projects
Projects are grouped together in a solution by the layer and module to which they belong.
Following is the example from Habitat project.
Image Source: Habitat project
A project, and assembly, should be named in a namespace-like fashion with:
- The overall customer, partner or solution name
- The layer (optional for project layer modules)
- The logical module grouping (optionally)
- The module name
- The logical function of the project
- File and Disk Structure
- Managing Sitecore Items
- Templates
- Page layout
- Configuration and settings
- Multi-site and multi-tenant
- Language and culture support
- Security and workflows
- Coding
- Visual Design and Theming
- Development
- Build and integration
- Testing
- Deployment.
In addition to above, there are principles/conventions for following which needs to be followed.
For more detail, you can look at http://helix.sitecore.net/
