Skip to main content


Sitecore Symposium 2019: Sitecore Helix


In this session, we learned how to use Helix and ways in which it is used incorrectly.  It also highlighted some of the updates in Helix 2.0 and showed us what to look forward to in future versions. Read more about my key takeaways on the patterns, anti-patterns, and smells of Sitecore Helix.
Sitecore Helix presenters


  • Helix usage is improving
    • 80% of people surveyed are using Helix in at least some capacity
    • Helix is changing based on customer feedback
  • What’s new with Helix 2.0
    • Updated the basic descriptions to help people understand the benefits of using Helix
    • Updated documentation to show how Helix patterns relate back to Uncle Bob’s principals
    • Included guidance on how to architect your solution for other Sitecore components
    • Included guidance on how to use TDS
    • New repository with Helix examples that are developer focused
    • Habitat is going away!
      • The name causes confusion
      • It was never meant to be used as a website starter template
    • Helix certification exam available now
  • Looking beyond Helix 2.0
    • Better multisite guidance
    • Helix for SXA

Warning Signs

  • Code smells
    • Indications there may be a deeper problem
    • Requires investigation
    • Easily identifiable
      • Including automated identification
    • May not be a problem
    • May not be worth fixing
  • Anti-patterns
    • Look like good methodologies, but can lead to issues over time
    • Should be remediated
    • Can lead to things that are not easily testable

Examples of anti-patterns

  • Cargo-cult anti-pattern
    • Using Habitat as a foundation for your project by changing the name
    • Copy/Paste
    • Brings along things you might not need
  • Atomic design as a feature
    • Feature.Component
      • Not necessarily a feature the customer can use by itself
    • Should group around business features
  • Fat foundation anti-pattern
    • One module that does more than one thing
    • Can cause dependency problems
    • Try to refactor and create stable code with correct layer dependencies
  • Slow builds, large solutions
    • Unnecessary build processes
      • Gulp
    • Creating multiple projects for each module even if they are not used
      • Test projects
      • Serialization projects
    • Using technologies you are not comfortable with
    • Use module boundaries that are right for your team and project
    • Consider breaking the solution into multiple solutions
    • Consider filtering the solution to only show/load projects you are interested in
    • Consider the SDK project format

Apply Your Expertise to Your Solution

  • Always be thinking about your solution architecture
    • Refactoring is evolutionary
  • Use principles as guidelines
  • Your implementation is special
    • Helix is a guideline not a list of checkboxes to follow
  • “Learn the song before you improvise”
    • Know the principles well, then change and apply to your situation

Helix Related Tooling

  • Sitecore TDS
  • FxCop rules for Sitecore Helix
  • Helix publishing pipeline
  • Sitecore
  • Sitecore installation framework
  • Updated gulp scripts
    • Much better and faster than before
  • Visual Studio Helix templates
  • Helixbase
    • Starter site in Helix

Helix Module Identification Patterns

  • Should I create a new feature?
    • Think about what code changes together?
    • Does it fit in the domain of an established module?
      • If so, keep it in the existing module
      • If not, create a new module
      • If you are not sure where to put it, put it in an existing module

Sitecore Helix Module

  • Should I create a new foundation module?
    • Do multiple features depend on this logic and is it non-trivial logic?
      • If so, create a new module
      • If not, keep it in the feature
      • If something may depend on it in the future, keep it in the feature


  • Why shouldn’t features depend on each other?
    • To ensure stable, non-cyclical dependencies
    • Decrease the cost of change
    • Avoid the build-up of technical debt

Sitecore Helix functionality
With so many great sessions at Sitecore Symposium, it was hard to choose just one. Don’t forget to check my session review page for additional notes from the event.

Thoughts on “Sitecore Symposium 2019: Sitecore Helix”

  1. Thanks for the article! I have a question regarding one of the points:
    “Should I create a new foundation module?
    Do multiple features depend on this logic and is it non-trivial logic?
    If so, create a new module
    If not, keep it in the feature
    If something may depend on it in the future, keep it in the feature”
    So what to do when only one module depends on this logic and it’s a simple logic? For example we needed to use social media links in EXM, so someone moved Feature.SocialMedia to Foundation.SocialMedia => only to be able to use an interface from that module. What would be the solution in this case? I really think Social Media should be a feature, but I don’t know how to resolve this issue. At one point we started to create modules in Foundation with suffix “Interfaces”, which would contain only interfaces and domain models. Some people don’t like this approach because then one feature has two modules and the dependencies between features are explicit, but they are still there.
    Regards, Kasia

  2. Hi Kasia! I’ve updated this post to include the slide about identifying foundation modules. This adds a little more detail than I was able to capture with my notes. Since no other module will depend on your socialmedia module (at the moment), it is best to keep it as a feature module. If at some point in the future other modules need socialmedia features, then move it to foundation. If you put it in the foundation now, you are prematurely optimizing for a case that may never happen. I hope that helps! Eric

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Eric Sanner, Solutions Architect

More from this Author

Follow Us