Spryker is the result of more than 100
It is based on the experience that extensible architectures are superior to large feature sets.
The system has a component-based core that is designed for high productivity
in future development.
Although the core of Spryker is a commercial product, the source code is open to the public. This is a new approach of software distribution which is called “Open Code“: Developers can retrieve the source code on Github and evaluate the framework if it fits to their needs. Spryker even has a contribution agreement. The difference to open source is the license that only allows evaluation.
So if you want to use Spryker for your project, we would be more than happy to talk with you
Design & coding principles
To achieve a highly flexible framework and ensure high productivity, we rely on established software design principles and clean code paradigms.
We strongly believe in the power of SOLID principles. We apply single responsibility to all of our classes, and wherever we need configurable behaviour, we use the open closed principle. Our subclasses always conform to Liskov substitution, and we use the interface segregation principle for communication between bundles, guaranteeing that interfaces only contain methods that are really required. We have separated infrastructural from functional code, modularized every functional unit into bundles, split every bundle into four layers, and isolated cross-functional code.
Separated front- and back-end applications
Spryker provides a slimline shop front end and a heavy-duty back end which contains patterns and infrastructure. This way, simple solutions to complex problems can be realized. Since no application can be both light and heavy at the same time, we have created two highly-specialized applications which communicate using remote procedure calls.
Seperation of core and project code pools
Spryker is divided into three code pools which are called „levels“. The core level contains all the code that comes from Spryker or other vendors. The individual implementations for each project are located on the project level. Finally, there is a store level which contains all localized classes and themes. These levels can be successively extended. Any class from the core level can be extended on project level and any class can be extended for each store
Bundles with versions
Spryker is subdivided into bundles which are functional units: for example, there is a bundle called „Customer Bundle“ which contains the database schema for customers, Zed’s backend GUI, Yves user account, and the business logic required for all use cases such as „log in“ or „register“. Only a small number of bundles are mandatory to run the system, and all other bundles can be installed via Composer. Each bundle has its own git repository and release number.
Bundles communicate with each other via internal APIs (facade pattern). Each bundle includes a part of the database schema, so when you remove a bundle, all tables and relations will also disappear. However, most of the bundles have very few or absolutely no dependencies to other bundles, so they can be replaced by another implementation which provides the same API. A clean dependency structure without cycles or illogicalities has a high priority in our work, meaning that you can easily replace Zed’s user management with a bundle that connects to your local LDAP.