Domain Separation with commercetools – Catalog

The ability to support domain separation is one of the features that makes commercetools an attractive choice for migrating an aging e-Commerce platform.  It doesn’t force you to use the system for everything, rather it allows you to use what you need and offload what you do not.  Furthermore, it allows you to move functions into the platform at your own pace. This article touches on the concept of using commercetools to own the cart and orders for an e-Commerce implementation while preserving the catalog outside the system.  

In a typical e-commerce implementation, you are likely to see a catalog, profiles, carts, and orders co-existing within the same application space.  In this model, you would have traditional domain coupling such as users with ties to cart or carts consisting only of items from the internal catalog.  This means that the logic to add items to a cart knows about the catalog and only allows the addition of items from the catalog.  Likewise, the logic to give a cart to a user has a reference to a user resource within the application.  Utilizing this traditional model is one of the choices a commercetools customer has:

Expected commercetools domain ownership.

 But what if you had a need to keep those domains separate?  Perhaps you already have a user service under some other application that is capable of tracking cart ids for each user.  Perhaps you have an established catalog service that is already in place and the idea of synchronizing that data or outright migrating it to another system is a non-starter.  Or maybe you are trying to figure out how to migrate your functions to commercetools but cannot take on all the domains in one ‘big-bang’ implementation.  Can commercetools support you then?  The answer is yes.

There are a couple of reasons why a business might have a need for an external catalog that feeds orders into commercetools.  Pre-existing catalog services may already be in place and keeping it synchronized to commercetools may not be cost effective.  Perhaps the SKUs do not fit the traditional retail model of product and SKU.  Maybe they need to be dynamically generated from user-driven configurations like one might find with an automobile purchase.

commercetools supports an external catalog through its CustomLineItem construct.  This is a custom object owned by the implementer but granted first-class citizen status within the commercetools application.  This means commercetools treats it like its own LineItem as if it came from the commercetools catalog.  A CustomLineItem is therefore included in price and tax calculations.  It is also included as an element which can influence or itself be priced by the promotions engine.  Finally it can be the target of API Extensions that refresh the object from its external source every time a cart updates.

A quick inspection of the fields illustrates the reason the custom line item works well for supporting an external SKU.  The key fields to note are the quantity, money, taxRate, totalPrice, and taxedPrice.  commercetools is aware that this construct needs to follow the rules of a typical line item in the cart.  For example, when the item quantity changes the price will too.  When tax is applied to the cart it is also applied to the custom line items using the same rules (or custom rules) as an item from the commercetools catalog.

The CustomLineItem construct is great for fees and complex SKUs alike.  If you are using it for SKUs then you likely need a sku identifier and perhaps other logistics attributes.  In the JSON above you can see the custom field ‘sku’ carries the SKU identifier.  The ’sku’ attribute is something the implementer has to define as a field.  commercetools provides the ‘fields’ object as a means to carry whatever attributes the item might need.  commercetools enforces type safety by requiring the implementer to define a ’type’ which is then used to validate the custom fields added to the line item.  Below is an example of what a type definition might look like.

The above illustrates how a CustomLineItem can be used to support an implementation where the SKU information is obtained from outside the system. commercetools can also be implemented to allow external control of other domains, such as users.  Thus it is possible to apply a domain ownership plan such as the one illustrated below.

commercetools is of course designed to handle ownership of each of those domains.  However, it remains flexible enough for domain separation if this is in the best interest of the business.  Domain separation may require some compromises.  For example, keeping orders separate from users may assume some external means to interface with commercetools to handle things like returns or customer care.  

The fact that commercetools is so flexible should put it high on any list when considering a new e-Commerce platform.

About commercetools

commercetools is a next-generation software company that offers a true cloud-native, headless commerce platform that provides the building blocks for the new digital commerce age.