What Is Virto eCommerce Atomic Architecture™?

Virto Atomic Architecture™ is atoms, molecules, cells, and organisms working together to create an effective ecommerce solution architecture. Using atomic design, the architecture of an ecommerce platform can be described by a set of composable elements. 

Virto Atomic Architecture™ is not a linear process, but rather a mental abstract model to help you think of ecommerce applications as both a cohesive whole and a collection of parts at the same time. Virto Atomic Architecture™ helps you create and maintain robust solutions, allowing you to roll out higher quality, more consistent solution architecture faster than ever before.

In Virto Atomic Architecture™, we present the following five layers:

1. Atoms
2. Molecules
3. Cells
4. Organisms
5. Cloud

The core concept behind Virto Atomic Architecture™ means to think about an ecommerce application structure as a universe where the smallest components (atoms) are included inside bigger elements (cells), which are included in even bigger molecules, and, the last enlargement step, they are in turn included in even bigger organisms. The organisms represent ready-to-run ecommerce applications to deploy in the cloud (Microsoft Azure, AWS, or other) as their living environment. 

Through the comparison to atoms, molecules, cells, and organisms, we can think of the solution architecture as a composition of self-containing modules put together.

Explaining Virto Atomic Architecture™, we focus on key principles that allow you to get a composable, flexible, manageable, customized, and easily updated e-commerce architecture that is fully adaptable to market challenges.

Our ecommerce platform development team can create their atoms, molecules, cells, and, finally, organisms. Accordingly, all these elements are ecommerce applications with an ecosystem living as an open sharing-economy community in which the parties share their experience and can reuse the elements like cells and molecules.

It begins at the smallest component level (atoms) and combines those to create larger components (molecules), which themselves get combined into still larger components (cells) that make up the applications (organisms). The result is an easily composable system with a large number of components that developers can select and assemble in various combinations to meet the specific business requirements of the online commerce.

Elements of each layer can be updated, improved, and evolved. The change in the functionality of the components helps to organically adapt them to new market conditions and business requirements. Just as in the world of living things, the most viable and efficient components are chosen by natural selection and receive priority in the ecosystem of applications.

Resource management and the ability to increase and decrease the load on the commerce platform allows you to control the cost and scale the business as it grows.

The components are scalable, that is, expandable. The platform is able to use the required number of components to run on demand. For example, the ordering system could be expanded independently of the catalog system, and both kinds of them could scale independently.

A successful implementation of the Virto Commerce platform is always the result of efforts from Virto, our partners, and clients’ dedicated teams. This means shared responsibility between teams while maintaining the hassle-free manageability of the development, customization, and platform support processes. Shared responsibility also means a high degree of trust with simple and straightforward rules for interaction between teams.

The simple, understandable, logical, and traceable Virto Atomic Architecture™ brings many benefits that allow companies to reduce the cost of platform ownership throughout its lifecycle.

It's clear what parts of the solution can be reused, and how they can be mixed and matched with other atoms, molecules, cells, and even organisms.

If a solution is created according to Virto Atomic Architecture™ principles, this means that all previously created atoms, molecules, and cells can serve as an architecture reference document. Also, you can control dependencies between the components.

The Virto Atomic approach allows understanding of the solution architecture much easier than one created in a more traditional way. The significant advantage is that you can review solution architecture on different layers from micro to macro in detail.

It’s easy to check which components are being used for different parts of the solution. This reduces writing duplicating code and allows precise control of the dependencies.

With Virto Atomic Architecture™ principles it is easier to explain the codebase to the new members of the development team. This is true not only during the time of creation, but in the future when a solution is being looked back on for reference or small tweaks.

As only one atom, molecule or organism is being changed at any one time, it is easy to ensure that any updates to a component are carried across to all other instances across the site. Similarly, unwanted components can easily be removed.

The ability to track the use of certain components in the ecommerce platform allows them to be clearly managed. If anything needs to get updated or deleted, you know exactly where to go and what to change.

Finally, the last benefit is the no-vendor lock, because you can replace any piece of functionality with either an internal or a custom one. We don’t practice locking, which happens often in the cloud environment.

As is often the case with abstract models, they step over their boundaries and original subject areas. 

To explain Virto Atomic Architecture ™, we present the following five layers:

1. Atoms
2. Molecules
3. Cells
4. Organisms
5. Cloud

Through the comparison to atoms, molecules, cells, and organisms, we can think of the solution architecture as a composition of self-containing modules put together.

Enough abstractions! Let’s delve into the structure of our real ecommerce platform, built of five atomic design layers. We will continue this post further, talking about each layer of Virto Commerce architecture.

Atoms are the most basic building blocks of this world. In solution architecture, atoms are the most basic elements such as modularity, API-first approach, security, events, background jobs, and others. Through the atoms, we can compose larger elements that resemble molecules.

Virto continuously works on the identification and improvements of the set of core atoms. But if it’s required, you can create a new one or customize existing ones, for example use a new type of database.

1. Should not be composed of other components/only uses native elements or framework-specific components like native elements.
2. Should not have access to a higher level directly.
3. Should not implement any application-specific business logic.

Being assembled together to get various functionality, atoms are composed of “molecules”. The second layer of Virto Atomic Architecture™ is a molecule level. 

An example of a molecule can be a catalog, prices, inventory, search, event bus, webhooks, and others. 

A molecule is a group of atoms and business functionalities that work together according to a single responsibility principle. Usually, the molecule has an API for communications with the other molecules and a database as persistent storage. 

Within the ecommerce platform, any molecule can be represented as a software module.

Let’s clarify single responsibility principles for some molecules. 

• Catalog – Responsible for catalog taxonomy, products, variations, and relations between products. 
• Price – Responsible for product price evaluation only. 
• Webhooks – Responsible for capturing events and helping to deliver them to third-party subscribers.
• Search – Responsible for full-text search abstractions above using engines like Elasticsearch, Azure Search, etc. 

At the molecule level, you can design your own molecules, for example, create a dynamic price, loyalty, etc.

1. Created from one or more atoms.
2. Built with a single responsibility principle.
3. Be headless, having API and events for communication. 
4. Have its own private persistent storage.
5. Support extensibility (injection, overriding) from other cells.
6. Should not have access to a higher level directly.

When molecules are placed in a functional interaction context such as a digital catalog, they become "cells". The term “cells” includes atoms and molecules required to obtain the desired functionality.

Cells are a set of molecules that are combined by functionality context into one package to implement a complete scenario. Cells are designed as scalable units; we can create new instances of cells, so each cell is a high-available, high-performance, and isolated container.

Examples of ecommerce cells can be a digital catalog, order, shopping cart, user profile, marketing, and so on. 

Digital Catalog – For most ecommerce solutions, a digital catalog should combine the catalog, price, inventory, search, and other cells as one entity and present it as an API for the client application.

Order – This is a full-featured order component with inventory, taxes, payment processing, etc. This cell is ready for integration with ERP via API and integration middleware. Usually, it contains either a webhook or event bus for proactive notifications between packages.

Virto creates predefined software packages by combining and assembling cells together. These packages can be extended or reassembled by the implementation partner or client to create customer-specific packages containing modules either from Virto, a partner, or custom ones.

How does custom package building work? Basically, you just create the configuration file and specify which modules you want to include in those packages. Then the tool will prepackage and prepare them for you to develop locally, so you can debug, troubleshoot, compile, and so on and also create the package to deploy into the production environment.

The packages can run locally on your own machine, so it's easier to develop them, or they can be deployed into the cloud initially or after the QA check on a local machine is done.

Virto Atomic Architecture™ doesn’t block creating as many packages as you want by a vendor or partner. Consider several different approaches to help you keep the number of components under control:

• Business oriented. You can deal with different requirements and continuously implement it. 
• Reduce costs. You use only the required molecules and cells and remove all that are unnecessary.
• Performance and scalability. You can scale up or scale down molecules quickly to suit your situation, allowing flexibility as your needs change. 
• Collaboration efficiency. Molecules are maintained by different teams and they can deliver new functionality and updates independently.

1. A complex component made up of multiple molecules.
2. Scalable and have multiple instances of cells working independently.   
3. Packaged, deployed, and run as an isolated container in the cloud.
4. Run on a local machine (on-premises).
5. Use an internal event bus for communication inside the cell.
6. Use asynchronous events, like webhooks for external communications. 
7. Implement application-specific business logic.
8. Have its own back office / admin interface.
9. Should not have access to other cells directly.

The fourth upper level in Virto Atomic Architecture™ is the analogy of organisms. This is a level of solutions that combines client applications (web, mobile, chart bots), packages, integrations, and third-party services (ERP, PIM). Usually, an organism is an abstraction of how the business and end user see it.

Organisms (aka solutions) are actually realizing business values and specifically client applications. Solutions may include additional third-party services. The ecommerce solution includes the front-end services (also called “head” in software architecture terminology) and necessary integrations that actually work outward. 

All elements in an organism use API for communications and can be deployed, scaled, and maintained independently.

All organisms in Virto Atomic Architecture™ live in the cloud. When you have an organism (aka solution) ready to run, you can deploy it in the cloud environment.

Note: That is, you can test solutions first locally (on premises), and then deploy in the cloud. This is because organisms are completely cloud-ready.

More and more businesses are actually interested in the cloud. At the same time, some of Virto’s largest customers – just because of the nature of their business – wanted to deploy more locally, having an environment and the kind of security they have.

For example, one large customer has a managed service provider that deploys all their software, so they prefer their packages deployed in their own environment. But again, there are some aspects of the marketplace that they consider important enough to deploy in ready-to-use cloud environments.

Get familiar with the meaning of each term mentioned above so the descriptions in Virto Atomic Architecture™ will be clear.

• Virto Atomic Architecture™ / Commerce Atomic Architecture – Innovative software application architecture based on Atomic Design by Brad Frost ideas. It defines the approach for building solutions and synergy between the Virto team, our partners, and our clients. 
• Atoms – Core capabilities and design patterns.
• Molecules – Group business logic functions together as a single-responsibility unit. The cell has its API and can have its storage, like a database.
• Cells – High performance, a scalable unit with a set of cells that are consolidated into one package to resolve business cases. Ex: digital catalog, orders, etc.
• Organism – Combines cells and client applications to deliver complete business value.
• Cloud – All organisms are living in the cloud.
• Vendor – Supplier of a platform built with Commerce Atomic Architecture.
• Partner (Implementation Partner) – Development team that can create additional functionality for the vendor’s platform.

Virto Atomic Architecture™ in ecommerce brings a fast way to innovation, because you can actually create new solutions using and assembling pre-existing modules. For example, we at Virto Commerce do that quite often with a new customer – where we need to showcase it, we just take the modules, integrate them into a Virto package, and then showcase them to achieve a custom look. This shows how the system can work and what it looks like.

The great benefit is the replacement of existing apps. For example, we have a few customers who have more advanced requirements for pricing, so it can be driven by the ERP, or it can be a very complex B2B scenario that our pricing engine doesn't support. In this instance, they actually write their own pricing module and then replace or extend our one.

The final point to remember is that the organisms (aka solutions) that work for us can be launched on local machines to test them, while they are ready to work and be launched right in the cloud.

Atomic principles also work for web design systems. Brad Frost describes atomic design as a combination of atoms, molecules, organisms, templates, and web pages. These elements work together to create effective interface design systems. If you’d like to read more about using atomic design for UI, visit https://atomicdesign.bradfrost.com.