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 modules, guaranteeing that interfaces only contain methods that are really required. We have separated infrastructural from functional code, modularized every functional unit into modules, split every modules 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
Modules with versions
Spryker is subdivided into modules which are functional units: for example, there is a module called „Customer Modules“ 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 modules are mandatory to run the system, and all other modules can be installed via Composer. Each module has its own git repository and release number.
Modules communicate with each other via internal APIs (facade pattern). Each module includes a part of the database schema, so when you remove a module, all tables and relations will also disappear. However, most of the modules have very few or absolutely no dependencies to other modules, 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 modules that connects to your local LDAP.