As I’ve mentioned in a previous post, my team and I are working on Sitecore Commerce StoreFront migration to Sitecore Habitat.
Before we moved to code itself, we dug into codebases of both projects to review their “as-is” implementation and we decided to come up with a plan on how to go to map functionality to Habitat so that it would comply with the principles it suggests. And here is what we found out and came up with.
Sitecore Commerce StoreFront Overview
StoreFront is an ASP.NET MVC 5 solution that provides a reference implementation for Sitecore Commerce Connect APIs for platforms - Sitecore Commerce and Microsoft Dynamix AX. The solution contains two subsets of projects (web projects and TDS)
- Common - share modules and logic used in StoreFront
- Platform-specific projects - functionality specific to Commerce or AX platform that cannot (or was not) abstracted and generalized or simply exists on one platform only. ** Our project was targeted on Commerce Server only so I will continue using it as a reference. Dynamics AX support might be added as well.*
Integration
The solution uses Connect and Commerce Server APIs to integrate with Commerce, however, they are not called directly from views or controllers. All API invocations are wrapped in a set of managers, which managers provide isolation and sharing of functionality. Managers, in this case, form a layer of business logic, while API might be treated as a data layer.
Presentation
The presentation layer is implemented using controllers and view, which are called based on item presentation details defined in Sitecore. In addition to that StoreFront has API controllers that are called directly from a client-side bypassing Sitecore. API controllers paired with Knockout.js are required to make pages more dynamic and responsive.
Sitecore
Within Sitecore, you would be able to find two content nodes for a commerce site: Global (keeps all configurations required from a site) and Storefront (this node contains page items with defined layouts and renderings). Communication between pages and settings is implemented via the StorefrontManager class.
More detailed information about Store you would be able to find on in Sitecore documentation or in code itself on Github.
Habitat overview
There are a lot of materials about Habitat available at this moment, like presentation series done by Thomas Eldblom. I will highlight a few principles here as they are relevant to our projects.
Layers & Modules
Habitat defines tree layers a bit differently than you might be used to in standard 3-tier architecture. In this case, it is not about Presentation-Logic-Data, but it is about functional relations and the structure of dependencies of modules within a solution.
The goal of the architecture above is to break down an application into a set of modules with clearly defined responsibilities and interfaces and normalize dependencies between them. Also, its main focus is on Domain or feature level, as this is a major part of an average implementation.
A feature, in this architecture, should contain every bit of code that defines functionality. This means that you would have a .NET piece, JavaScript, and even HTML (semantic only) in this layer.
Commerce StoreFront to Habitat Mapping
As you see from the overview above implementation approaches are quite different between Storefront and Habitat, so we decided to start from high-level mapping to layers defined by Habitat modular architecture.
Layers mapping
Our first thought was to go and move all StoreFront managers to separate features, as they seem to be covering different functional subsets in the e-commerce domain. However, this would complicate the feature layer significantly as we would need to maintain many dependencies between feature modules.
So we decided to treat managers as well as Connect API as a foundational API that we would use across the domain layer in the Habitat approach.
We believe that this is the right approach to CMS integration should have minimum required exposure to commerce logic. Ideally, it should just help to configure required components on a page and proxy requests to an underlying commerce platform. This would support the separation of concerns on a platform level.
The domain layer, in this case, contains controllers that handle communication between Sitecore presentation components and client-side scripts and Commerce Server. The image above illustrates the catalog feature dependency.
Features mapping
On the domain layer we formed 4 features:
- Account - this feature replaces a similar one in Habitat, as in the case of StoreFront it provides a lot of functionality specific to commerce implementation, like order history.
- Catalog - it is responsible for various presentations of product data starting from product listing to product banners.
- Check out - the feature fully handles checkout from review order to confirmation page.
- Search - handles search and content searches on the site.
Project layer
We keep the structure of the project layer similar to the original. We got rid of the Demo project as it is not used and we adopt the Habitat project to glue new components to pages as it was planned for.
The following pictures show how Storefront was finally mapped to a Habitat:
In the next post, I am going to cover implementation details of one of the features from the Domain layer.
Posts in series
- Inception: Sitecore Storefront to Habitat Migrating
- Mapping Sitecore StoreFront to Habitat
- Sitecore Catalog Feature for Habitat
Follow me on Twitter @true_shoorik. I would be glad to discuss the ideas above in the comments.