One of our main goals in Spryker’s architecture is a high degree of modularity. The idea is to split the system into functional units. Each one of them has a single responsibility and well-defined dependencies. We call these units “Bundles”. Any other term, however, like module or package would also apply here. A bundle contains everything needed to deliver a particular functionality like business models, controllers, schema, queries, etc.
We experienced that it is not a simple job to design a truly modular system. But we do it for a reason. Our clients can choose from a wide range of bundles. At the moment we offer around 120 bundles like Cms-, Customer-, Product-, Sales-, and Search-bundle. Not every client of Spryker needs all of them. Making Spryker even more modular allow our customers to choose only what they need in their different projects. Maybe you operate an e-commerce business that does not have an inventory with stocks (e.g. downloadable products). In this case you can remove the Stock bundle and also the dependent Availability bundle. This way, you keep your code base lean and avoid side-effects in your implementations. Less code also speeds-up indexing in your IDE. Another benefit for our clients is the possibility to replace a single bundle in case of heavy modifications. This approach will help you to keep all other bundles compatible with future core updates while in parallel developing something custom on your side. To give an example: Let’s say you sell cereals that can be mixed up by your customers in the shop. So instead of products with a stock, you have ingregrients with a base price per 100g. This is conceptually different to Spryker’s catalog, but the good news is that the modular approach of Spryker allows you to replace the related bundles (e.g. Product, Stock, …) with your specific implementation and yet still use the rest of Spryker’s bundles without modifications. Our academy explains in detail how to replace a core bundle.
The biggest benefit for our clients is the possibility to update only parts of Spryker. The core team of Spryker implements and applies an Atomic Release Process. So every new feature is developed independently and affects only a single or a few bundles. Instead of a big giant release every quarter with unpredictable large migration efforts, our clients get a stream of small incremental releases and they can decide which one is worth the migration effort. I described the challenges of the process and how we tackle them in the last blog post.
In the next blog post, I will explain the technical challenges and our solutions to make Spryker a truly modular platform.