This article will provide the overview of
Sitecore Helix recommendation and conventions which will help you in Sitecore product implementations:
• Highlighting what’s new in Helix 2.0
• See how to identify the candidate for Feature/Project/Foundation
• Tools to support Sitecore Helix
I would like to thank Derek Correia and Nick Wesselman for sharing useful information on Sitecore Helix Patterns, Anti-patterns, & Smells - What's New with Helix/Habitat? at Sitecore Symposium 2019 in Orlando, FL.
The Contents of the post are:
• Overview of Helix
• What’s new with Helix
o Lots of changes done in Helix documentation
o New appendix in Helix documentation
o Sitecore Commerce
o Alternate/consolidated project architectures
o New repository of developer-focused Helix examples
o Habitat reference removed
o Many updates are under construction
• Sitecore Helix Recommendation and Conventions – Helix Smells
o Principles of Package Design
- The Principles of Package Cohesion
1. The Reuse/Release Equivalency Principle (REP)
2. The Common Reuse Principle (CRP)
3. The Common Closure Principle (CCP)
- The Principles of Package Coupling
4. The Acyclic Dependencies Principle (ADP)
5. The Stable Dependencies Principle (SDP)
6. The Stable Abstractions Principle (SAP)
o Helix Smells
- What is Code Smell
- What is Anti-patterns
- What is Helix Smell
o Identify smells and anti-patterns
- Habitat Cargo Cult
- Feature Refactoring
- Fat Foundation/Fat Project
- Unearned Foundation Status
- Slow builds, large solutions
• Tools
o Sitecore TDS
o FxCop Rules for Sitecore Helix
o Helix Publishing Pipeline
o Cake.Sitecore
o Sitecore Install Framework (SIF)
o Helix Visual Studio Template
o Generator Helix
o Helixbase
o Get Redundant Fields
• Overview of Helix:
Helix is a set of overall design principles and conventions for Sitecore development.
Habitat is a real 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. It also provides an excellent basis on which to develop additional modules and extend existing ones.
Helix helps in controlling dependencies clean and easy to maintain code base, and information architecture.
• What’s new with Helix:
The Sitecore is working towards making guidelines/Principles to make product robust. In the same line, Sitecore every year collects the feedback from Sitecore Community to include reviewed requests into future enhancements and releases.
Forms of collecting requests:
- Developer Experience Survey
- Interviews
- Slack #helix
- Twitter trolling
- Helix Requests for Comment (RFCs) |
|
o Lots of changes done in Helix documentation
Credit: Sitecore
o New appendix in Helix documentation: How do Uncle Bob's Principles of Package and Component Design reflect in Helix?
Credit: Sitecore
Credit: Sitecore
o Sitecore Commerce:
Guidance on solution architecture when code needs to target additional Sitecore services. Guidance on how to structure a module when using TDS.
Credit: Sitecore
o Alternate/consolidated project architectures:
We can also follow Helix principles in creating logic boundaries for module (a.k.a. fewer Visual Studio Projects). In this case we can use FxCop to create logical boundaries for modules instead of physical ones
Credit: Sitecore
o New repository of developer-focused Helix examples:
Available now: Helix Basic Company
– TDS
– TDS – Consolidated Projects
– Unicorn/Helix Publishing Pipeline
Coming next:
– Helix Corporation
– Helix Franchise
o Habitat reference removed : no longer will be used in documentation and Helix will be present to avoid the confusion.
https://github.com/sitecore/habitat
https://sitecore.github.io/Helix.Examples
Credit: Sitecore
o Many updates are under construction
• Sitecore Helix Recommendation and Conventions – Helix Smells : In this section I will be explain about Principles of Package Design on which Sitecore Helix practices are based
o Principles of Package Design:
- The Principles of Package Cohesion
Martin’s first three principles deal with what goes into a package, and what stays out.
1. The Reuse/Release Equivalency Principle (REP) :- A module should serve a single business audience. 
If you are creating any module/feature in your application then it should serve a single purpose. In the above example, we are having Navigation module/feature which is serving same type of functionalities like Main Navigation, Footer Navigation, etc.
2. The Common Reuse Principle (CRP) : classes that are not bound to each other with class relationships should not be in the same package.
SOLID principles: Interface Segregation Principle
In the above example, Login module at Feature layer will serve complete business logic and if any site-specific configuration changes required in Multi-site implementation then its always recommended to create Site specific templates at Project layer which will be inheriting from the Feature layer templates.
This is why even with Data Source packages, Helix recommends a separation between the interface template, owned by the module, and the Data Source template, owned by the Project layer
3. The Common Closure Principle (CCP) : The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package and no other packages.
This principle motivates the Helix practice of grouping different types of elements (templates, renderings, views, controllers) that collaborate to produce a feature.
For example, imagine adding a new behavior to a navigation package, with a new field added to an interface template, new code added to a model repository, and new markup added to CSHTML. Although these are different technologies, they are bound in one Helix module, and thus the impact of the modification is limited to that module.
- The Principles of Package Coupling:
The last three principles define how packages (i.e. modules in Helix) should interact with one another.
4. The Acyclic Dependencies Principle (ADP) : No cycles will be accepted in the dependency graph.
This principle guards against circular references and dependencies, so that the direction of dependencies flow in one direction
The reason for this precaution is that if a circular dependency is allowed to stay, then a change to the offending package will mean that every other package will need to be validated, undoing the benefits of modularization.
Visual Studio will guard circular Project reference
For example, Helix requires that fields always be addressed by Field ID rather than field name, as by using field names a module takes on an implicit dependency on every other module in the system not to have overlapping field names.
5. The Stable Dependencies Principle (SDP) : Code should depend in the direction of stability
Packages that change rarely should not depend on modules that change often, as this reduces the benefit of modularizing stable code.
In Helix: all features should live in “Feature”-layer modules, and no Feature layer module may depend on another.
6. The Stable Abstractions Principle (SAP) : A package should be as abstract as it is stable
Open/Closed Principle
> In Helix, this principle is observed by keeping the Foundation layer “conceptually abstract”: free of markup, and not directly servicing business audiences, but rather enabling the Feature modules that do so
> For example:
* Comments – Can only add comments if the user is logged in and you use their name from their profile data.
* News – Can only see certain news articles if you are logged in.
* XXX – Soon other modules, will need to know if the visitor is logged in and their name.
>In general if a module depends on a 3rd party system they are very unstable, as you cannot control when their API will change. This is one reason that moving the code to the foundation layer is NOT a good idea.
>Introduce a new Profile module in the foundation layer, which contains the abstractions/interfaces that models the data/services for the Profile module. And rest of the logic to access the services (integration) can be done at Feature level by using DI to create the object of Foundation layer and fill the data, but service call from Feature needs to be initiated by using DI of service layer object in Foundation.
o Helix Smells : Before deep dive into Helix Smell, first we have to understand what is Code Smell..
|
What is Code Smell: |
The term was popularized by Kent Beck. In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.
Issues can be:
• Duplicated code
• Forced usage of overcomplicated design patterns
• Large class
• Dependency
• Cyclomatic complexity
• Method having too many parameters
• Long method
• Other items..
Code smells indicate a problem, that needs further investigation to determine whether action is required or not.
|
|
What is Anti-patterns:
|
A pattern/principles/guidelines used to improve the application lead to more bad consequences than good ones.
Issues can be:
• Big ball of mud: A system with no recognizable structure (not well defined)
• Database-as-IPC: Using a database as the message queue for routine inter-process communication where a much more lightweight mechanism would be suitable
• Constant interface: Using interfaces to define constants
• Circular dependency
|
| What is Helix Smell:
|
The term was popularized by Martin Davies. The Sitecore implementation not developed by following the Helix defined guidelines.
Issues can be:
• Unwanted code from Habitat used in Client’s solution without need and might be any redundant code. Habitat used as starter kit #HabitatIsNotAStarterKit,
• Replacing “Habitat” with “YourCompanyName”
• Helix isn’t a scorecard, checklist, or required architecture
• Helix isn’t the only way to build a Sitecore Solution
• Redundant code
• Module identification
• Not proper refactoring
|
o Identify smells and anti-patterns:
- Habitat Cargo Cult : Cargo-Cult Programming occurs when developers include code in a system, but do not know or understand the reasoning why that code needs to be included; they only know that by including said code, the program works as intended.
* Unwanted code from Habitat used in Client’s solution without need and might be any redundant code.
* Replacing “Habitat” with “YourCompanyName”
* Helix isn’t a scorecard, checklist, or required architecture
* Helix isn’t the only way to build a Sitecore Solution
* Identification of feature being done on the basis of functionality and no grouping
* For example, Tabs, Accordion, Promo Content, Hero Image are functionality but serving the one Business Feature i.e. Used to display the Interactive Content.
* Create a single feature appropriately named with the responsibility of the components contained within different controllers.
* Responsibility != Feature
Go through following Feature Module identification (new functionality) flow before introducing new feature/module:
- Fat Foundation/Fat Project:
* Large amount of code
* More than one responsibility
* Unstable module: e.g. ‘if’ statements, one currently dealing with product details and the other, Blog details, for new option code needs to be changed.
* Review the number of responsibilities the code has and see if refactoring makes sense.
* Consider your interfaces in Foundation modules and chart them – do they make logical sense to the modules using them?
* Exception: Support patches and Hotfixes
Go through following Foundation Module identification flow before introducing new module:
- Unearned Foundation Status:
* Where code in the Foundation layer is only used by a single Feature module.
* 1:1 dependency between Feature and Module.
* Another common scenario I see is when there are multiple features, but only one is dependent on foundation modules
- Slow builds, large solutions:
* Unnecessary or uncomfortable automation as part of the build and deploy process (Gulp)
* Creating multiple projects for each module, regardless of if they are used or not (Tests, TDS for modules with no items).
* Use module boundaries that are right for your team and your solution: projects, folders, or project-per-layer, for example VS Solution Helix.Examples
* Use technologies with which you and your team are comfortable.
* Don’t like gulp? Use chef! Or MSBuild! Or anything else!
• Tools : Following tools can be utilized
Comments