When we designed Spryker, our goal was to create an architecture that works well for small Taskforce-like teams as well as big clients with large teams and ambitious backlogs. We know that heavy development on top of monolithic software quickly results in a mess. Even simple changes cause a cascade of subsequent changes in dependent modules. Coupled code can not be reused and there can be lots of unforeseeable side-effect when things are changed.
To tackle these symptoms we divided Spryker into coherent and loose coupled functional units, which we call bundles. They contain a definition of their dependencies via Composer and have their own (semantic) version. You can see this structure on VersionEye. This way developers can safely work in parallel in different bundles with clear responsibilities but without merge conflicts and other negative side effects. Single change-sets can be deployed separately which is a requirement for a high productive Continuous release process.
Our academy provides a full documentation of Spryker’s feature set. A list of all released bundles is available on Github. To give it a try you can install our demoshop which represents a possible usage of around 100 Spryker bundles.
Why not a distributed system?
We also researched if we benefit from encapsulating bundles or cluster of bundles into small applications (or Microservices). Eventually we decided against it because of the disadvantages of a distributed system like latency, outages, security, etc. It’s so much simpler and faster to call a method of an object in the same application instead of doing the same call via network. The real benefit comes from modularization and consequent implementation of the SOLID and Clean Code principles. Most of our clients have a SOA-like IT landscape with PIM, Data-Importers, ERP, MAM, etc. This is a perfect use case for Spryker which provides a separated shop frontend application (Yves) and backend application (Zed).
In your project there may be good reasons to realize a service infrastructure with small (or even micro) services. Because of Spryker’s consequent internal modularization you can easily split it into smaller parts. E.g. you can have one Zed for Catalog-Management, one for Order-Management and another one for Customers, etc. This split does not work out of the box yet, but it can be done with reasonable implementation effort. If desired you can have completely separated teams and deployments. You can even switch to other programming languages and replace parts of Spryker. Internal facade calls can be wrapped with a service-layer and transformed into remote procedure calls.
What about Self-contained Services (SCS)?
In case you are looking for Self-contained Services (SCS) you can realize it with Spryker as well. Spryker supports the Twelve-Factor App Methodologyand therefore it can be installed on almost all PaaS providers. For instance we have a demoshop that runs on Heroku (read more here). This way Spryker is ready to become containerized with Docker.