Decoding — Sitecore Habitat — Part 1 (Introduction) !
I hope, if you are reading this blog post, you would know what Sitecore IS and what Helix Principles ARE and what Habitat IS!
Don’t worry if you don’t remember them now ! :) Together let us explore, the details of the Habitat project. If you are Sitecore developer, you might looked at this Habitat project many times, but I wonder whether you have time to looked deep in to the implementation !
Sometimes you might be thinking you can take the Feature, Foundation & Project (Visual Studio Projects ) AS IS and use it in your new project, but practically you may find it difficult, but in some cases you would have used some parts of the project.
This series of blog post will help you to see the Habitat project with extra lens and helps you with practical ‘TIPS’ to implement in your project.
If we need to understand the Habitat, we need to ‘Zoom Out’ overall implementation and see how the Habitat Solution looks like !
Overall Habitat implementations can be classified into 4 Dimensions !
- Habitat Website : A working proof for the Helix principals implementation. Whatever explained in the Helix principals were practically demonstrated on the website implementation.
- Content Structure : The most important part in the Sitecore, that every developer should understand what to do, what not to do in creating the content structure.
- Visual Studio Solution : The code that wires the Content Structure and the Business logic. One of the best reference implementation shared by Sitecore to the community is Habitat code base.
- File System : Many a times, the development team consider storing files in the file system as least priority, but Sitecore Helix Principals stress the importance of maintaining the files in specific way.
What is the Architecture principle do you see on the Habitat implementation ?
Modular Architecture, the beauty is that you can replace or add any one component without effecting the rest of the system.
In the below example product ‘Car’ has many modular parts, putting the parts together, we get a complete product. Also we can change the module independently, without effecting the other parts of the car. Similarly the Habitat was developed to demonstrate how modules based development can be done in Sitecore.
Modularization concept can applied to wherever a complex system has to be build and managed.
The Habitat solution was build based on the Helix principals, let us look at the ‘How’ these principals are categorized.
Helix principals are broadly categorized into two buckets one as Patterns, Principals and Conventions, the other is DevOps and development life-cycle Management.
If we further look deep at the principals, around 70% principals talks about the Content and around 30 % on the non-content related (concepts). The development team should understand the non-content concepts, before start working on the Content related aspects. The non-content concepts will determines the overall approach to the implementation.
Helix also recommends the approach for development & unit testing, as well on the devOps process build and deployment. Which we can use these principals as a comprehensive guide for the complete life-cycle implementation.
Architecture Principals
Let us further ‘Zoom In’ to the most important Architecture principles recommended in Helix .
Do you know what are 3 reasons you need to use Helix Principals ?
1. Offers productivity benefit (during the development and maintenance).
2. Durable — able to exists for longtime, how long the developed code can sustain to the future changes.
3. Quality, unless we set the guidelines for development, we can’t measure the quality.
What are the fundamental principles that Helix is based on ?
The Object Oriented principals are base for the Helix Principals, the modern development approach is strongly influenced by the Object Oriented programming. Sitecore leverages this Object Oriented principals put together most relevant principal for Sitecore development and call it as Helix Principals.
How to call the feature and functionality hereafter ? What is recommended in Helix ?
If you are experienced Sitecore Developer / Lead / Architect, you might be using the word Component. In Helix Principals is recommending to use more generic word Module. ( I hope you will start using the word module here after !!!)
What basis I should define a Module ?
Have you heard about Common closure principals ? The change in one class has impact to the other classes needs to be put into one module.
Classes that changed together should be packaged together.
For example FAQ module combine all the business related functionality, stands independent from other modules, it contains related front-end, business logic and content & templates. Such modularity gives flexibility to add or remove the module from the website.
In real life, have you seen the modules/component that needs be changed or fixed, is detachable ?
Also module should implement Single Responsibility Principle .
Do I really need to be cautious about ‘naming’ modules ?
Yes, you should consider this as a top priority in any new project development, because a common terminology between the developers and business will iron-out the differences throughout the project execution. The below table provides a comparison of good and bad module naming, it is recommended to use business centric naming than type centric naming, the list is just for reference purpose only.
Is the layering done in Sitecore is similar to MVC ? If not why ?
No, the layering recommended in Helix is completely different from MVC. In n-tier or 3-tier architecture, the presentation, business logic and repository or database will be the layers.
But Sitecore recommends to use Stability Dependency Principle to create projects in Visual studio.
The Stable Dependencies Principle states a package should only depend upon packages that are more stable that it is. If they don’t, changes in an unstable package can have side-effects in a stable one.
It is not recommended to create any additional layers in Sitecore Project, also the bottom layer should be more stable than the layer above. The dependency can be established within foundation or feature or project layer, but there should not be any cross dependencies.
I hope you enjoyed reading the blog and understand something new on Helix Principals!
Have a great day !!!
