Mapping Sitecore StoreFront to Habitat

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)

Components.png

  • 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 logiс, while API might be treated as a data layer.
2016-07-23_1747

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 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.

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 structure of dependencies of modules within a solution.

2016-07-23_1817

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. Which mean that you would have .NET piece, JavaScript and even HTML (semantic only) in this layer.

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.

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 e-commerce domain. However, this would complicate feature layer significantly as we would need to maintain many dependencies between feature modules.image2016-7-22 14-44-28

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.

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 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.

Project layer

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:
2016-07-24_2314

 

In the next post, I am going to cover implementation details of one of the features from Domain layer.

 


Posts in series

  1. Inception: Sitecore Storefront to Habitat Migrating
  2. Mapping Sitecore StoreFront to Habitat
  3. Sitecore Catalog Feature for Habitat

 

Follow me on twitter @true_shoorik. Would be glad to discuss ideas above in comments.

 

Mapping Sitecore StoreFront to Habitat

6 thoughts on “Mapping Sitecore StoreFront to Habitat

  1. Great initiative! Lots of attention internally in Sitecore on your project.
    One comment: Please avoid technology specific naming in your Habitat modules. Part of the concept is to abstract the technology away – and there I would suggest something neutral such as Foundation.Commerce instead of Foundation.CommerceServer.
    Looking forward to next post – and access to the code 🙂

    Like

  2. Newbie says:

    I have a problem when I try to port code from Store front to Habitat. The problem is “How we implement routes in habitat project?” Anyone can make a suggestion.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s