As I’ve mentioned in a previous post, my team and I are working on Sitecore Commerce StoreFront migration to Sitecore Habitat.
Before we actually 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 a 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.
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 logiс, while API might be treated as a data layer.
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.
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 setting is implemented via StorefrontManager class.
More detailed information about Store you would be able to find on in Sitecore documentation or in code itself on Github.
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 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.
Commerce StoreFront to Habitat Mapping
As you see from 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.
Our first thought was to go and move all StoreFront managers to separate features, as they seem to be covering different functional subsets in e-commerce domain. However, this would complicate 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 domain layer in Habitat approach.
We believe that this is the right approach to CMS integration should have minimal 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 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. An image above illustrates the catalog feature dependency.
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 products 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.
We keep the structure of 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.
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 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. Would be glad to discuss ideas above in comments.