When you are about to go headless, you will be in control of your own data model for commerce and is not just limited to the representation provided by the vendor of your headless platform. If you are a consultant with multiple implementations, you may take the oppurtunity to align several clients to use the same data model for easeier code reuse. In this blog post, I will address the question why you should want to have your own model and not be limited only to use the model provided by the vendor.
This blog postis the first in a series of blog posts explaining how to implement an e-commerce application on top of an existing CMS and headless commerce solution. For examples in the future posts, we will be using Sitecore and Umbraco as CMS and Storm Commerce as the headless commerce platform.
The layers of an application
But before we address the data model, we need to find out the purpose of why there may be a need for a data model different than the one provided by the vendor. This applies to you if you are using a multi layered appliction where some of the interaction with the end users includes exposure of the data in Json for the presentation layer.
The managers layer
This is the bottom layer that I’m using for accessing data from the systems where it is stored. Each manager has it’s purpose to be responsible for the business logic understaning how the systems underneath the managers layers and the database data is structured. Each manager is there for one purpose and is only allowed to perform actions in it’s own domain. Managers are managed by dependency injection. The managers are using the internal data model that is an implementation of the externally exposed interfaces on top of the model.
The services layer
A service may interact between multiple managers and is responsible for coordinating which managers that are invoked to perform a task regardless of how many managers there are. Each service has a constructor where it will receive it’s managers required by dependency injection. The service is invoked by the layers above and does expose the objects customized for the specific customer. To be able to reuse the data model, make sure that this model is only communicating by interfaces of the domain model. This layer may expose the data transfer objects implementing the interfaces of your domain model.
The frontend backend layer
This is where the logic happens that will be in interaction with the end user and where most of the code will not be shared between different clients except for the base functionality of an e-commerce site. This layer is allowed to communicate with the layers below by using the services layer. This layer will have no knowledge of the systems underneath and their implementations, it will just be aware of the services layer and the Data Transfer Objects data model. It will have the services required injected by dependency injection so that it does not know exactly which implementation of a service that is used, which will make it easy to replace a service underneath to provide customer specific logic in the service layer without altering the contract between the service and the models underneath.
The domain model
In order to be able to have code reuse and to not be totally dependant on to always keep the same infrastructure, I would recommend you to build your own data model on top of the systems that you are interacting with in your implementations, so if you decide to replace the customer services system with a different one, you don’t need to start all over again. This is why I’m always using the data model in three layers.
Top layer Data Transfer Objects
This layer is what may be exposed as JSON objects through my controllers. It is sufficient to do basic calculations and logic on, but is totally independant on which backnd system that is being used. It will implement an interface that allows this data transfer object to be sent down to the system levele underneath with the use of reflection or similar technologies.
The implementation layer
This is where the data model is managed so that it may contain all the attributes required to do business logic on them but where not all the information is intended for the top layers. It is i.e. irrevevant to expose purchase details about a product to any layer above or any kind of data that is not supposed to leave this layer. There are methods on this layer to transform from and to the data transfer layer and methods to interact with the vendor data model.
The vendor data model
This is the data model provided by the vendor. This model is used to send requests and interpret responses from the vendor. There are often different models from different vendors, such as the e-commerce headless commerce platform with it’s data model and the CMS that may also keep information about e-commerde data such as customer logins.
The result will be a model where your frontend logic will communicate down to the below systems using Data Transfer Objects (DTOs) and they will respond back in that way. You may replace the managers and services in different projects if those that you implement won’t do the job for the current project, but the data structure will be intact. Remember to use Dependency Injection to support this model.
About this series of blogs
This is the first entry in a series of entries to spread knowledge on the topic for how to implement an e-commerce solution that depends on one ore several underlying SAAS systems and local software.
The author, Fredrik Gustavsson at Jolix AB is working to spread the knowledge on how to be able to do this using standard platforms and how to be able to reuse code between clients.
Fredrik Gustavsson