Sitecore Helix: 6 Principles of Module Design

6 Principles of Module Design

Introduction

Sitecore, driven by partners in both Technology and Solution implementation. Partners bring with them an army of highly talented and goal oriented developers to solve the numerous digital age business problems. The fabric of collaborative Sitecore developer community always come up with their innovative solutions for almost any complex problems. These solutions explain the thought process, generate new ideas and more interestingly enforce the underlying development style.

Coming through various regions, languages and organizations often impact a certain development style. So, whom do the next generation developers follow? What is the best practice in Sitecore development? Though this question was answered by a few idealists in the developer community, never it was enforced. If we look at successful organizations, one thing we always notice would be they plan, provide guidance, lay rules and have tools to support same.

So, Sitecore came up with a solution ‘Helix’ to help all its current and future developers. In short, Sitecore defines Helix as:


So, where does Helix fit in?

As we all know change is the only thing constant and cost of change will increase over time. A good architecture will deliver maintainable and extensible solutions and reduces the cost of introducing new changes. So, to understand helix conventions better it is necessary to understand the underlying principles of developing a better modular architecture

Below picture shows the relationship of Conventions to Principles.

Relation between principles, conventions, examples and tools

Fig. Relation between principles, conventions, examples and tools


To deliver a modular architecture one should move away from monolithic architecture where everything sits in one and demands changing everything for simplest of development. It is good to separate things into different parts, identify the dependencies and manage them. And that is what the principles of package design is all about.

Principles of package(module) design


There are 2 major focus areas of package design
  1. Granularity - Talks about how to define a module and how to make them manageable. What should be in module what should not be.
  2. Stability - Talks about how modules should connect and how to do stable implementations

Under Granularity we have 3 principles that talks about Package Cohesion

  1. Reuse-Release equivalence

    1. Ship all or none
    2. Should serve same audience
    3. Module content should be from potential customer use

  2. Common-Reuse

    1. Tightly coupled classes will be in one module
    2. If you reuse one - reuse all

  3. Common-Closure - This is the place to look for bloating. Follows the OOD Single-responsibility principle. Should not be generic with multiple responsibilities.

    1. A change in one module should not change something in other
    2. Single-responsibility principle (SitecoreExtensions in Habitat is exceptional; has multiple responsibilities)

Under Stability we have 3 principles that talks about dependency between different modules

  1. Acyclic-Dependencies

    1. No Circular dependency

  2. Stable-Dependencies - This is how Habitat structure is developed. Identifies the volatile modules that need changes frequently. Should not have many abstractions.

    1. Common closure principles
    2. volatile module depends on stable ones

  3. Stable-abstractions

    1. Stable ones need to be abstract
    2. Stability should not prevent from extension


References:





Comments

Post a Comment