This article will describe some of the basic architectural choices that the Commerce team has taken in the architectural process - seen from my point of view. I have not been part of the process – so my description is solely seen as an external architect with Sitecore, Commerce and technology experience from 25 years in the market. So – what are some of the choices that I find most interesting:
1. BUILT ON .NET CORE
Building on .NET Core is something Sitecore started doing with the Publishing Service. It makes a lot of sense to start the migration towards the new Microsoft architecture when possible. It raises the bar for hosting environments and developers – but could potentially mean we could run Sitecore Commerce on other platforms like Linux. For some organisations that would mean something.
But from my point of view it is the movement that is important. We all still struggle with solutions having XSLT, WebForms is stilling used and active – so moving to .NET Core renews things big time – and requires the solution development teams to move as well. Sometime force is the best way forward – so I like this.
2. MICROSERVICE ARCHITECTURE BASED ON REST/ODATA
Building on a microservice architecture with ODATA structures makes the Sitecore Commerce engine very accessible from many different areas. We find it very relevant to be able to integrate Commerce activities (both order generation, order history and customer interactions) with other systems such as POS systems (being able to validate vouchers and gift cards offline),
Customer service suites (Zendesk can see directly into a customer order history without data replication), third party order generations (being as advanced as EDI or as simple as separate order entry systems).
3. PLUGIN BASED ARCHITECTURE
The component based architecture which is heavily relying on inversion of control principles as well as SOLID design principles. Building the product from the core and up based on plugins validates the extensibility already from the product foundation.
Now the rest of us just have to pick it up (some extensions have already been announced by Sitecore Commerce Partners).
The plugin’s will inject themselves into the REST/ODATA apis automatically by composition – which means your plugin development does not need to cater for actual API actions.
4. FLEXIBILITY IN DEPLOYMENT
Utilizing the microservice architecture means that we can have a large degree of flexibility in the deployment options – from a single monolith with all services running on the same box (typical development mode) to a redundant and scaled setup. With microservices, we can scale according to needs – so our minions service (a asynchronous task runner) can be run on several machines if needed, while others can run in a more limited setup.
So – from a software architecture point of view, I find the Sitecore Commerce platform to be very interesting. It offers the individual developers a good foundation for understanding and exploring the platform by utilizing the new generation of frameworks and tools. These are well supported and documented by platform vendors. At the same time, the architecture leaves us - Sitecore Commerce partners - room for making a difference – the extensibility architecture means we can create ourselves components and accelerator packs for either reselling or just enabling our own teams for faster implementation.
This was a quite high-level view of what I think are the important, architectural decisions made by Sitecore during the Sitecore Commerce development.
I will be back with more opinionated insights into the tools and the development model needed to work with Sitecore Commerce and the Sitecore Experience platform.
KLAUS PETERSEN
Global CTO
