{% extends 'Layouts/Doc/default.html.twig' %} {% block title %}{{ 'app.documentation.menu.architecture.overview'|trans }}{% endblock %} {% block headerPageTitle %}{{ 'app.documentation.menu.architecture.overview'|trans|upper }}{% endblock %} {% block body %}

Architectural drivers

All architectural decisions need to be backed by a valid reason. The fundamental signposts we use to take such choices, are explained in Architectural Drivers section.

Architecture

On the below image you can see the symbolic representation of Popina Order architecture.

Architecture

Keep on reading this chapter to learn more about each of its parts: Admin, Shop, Cash register, API, Core and Bundles.

Division into Core, Admin, Shop, Cash register and API

Core

The Core is another component that integrates all the other components. The Core component is where all the logic and implementations that are useful for our project's operations are gathered.

Popina Order has here a fully integrated concept of everything that is needed to run a webshop.

Admin

In every system with the security layer the functionalities of system administration need to be restricted to only some users with a certain roles:

  • Administrator: Full access to configure the project ang global options, and access to all franchises and shops.
  • Support: Read access only to all franchises and shops to help our clients.
  • Manager: Full access to configure his franchises and shops.
  • Shop owner: Full access to configure his shop.

Shop

Our ShopBundle and FranchiseBundle is basically a standard B2C interface for everything that happens in the webshop's system, where the clients can make and pay their orders. Also here views have been built using the ReactJS.

Cash register

When enabled, all orders made from the webshop are send to the cash registers existing in the physical shop(s).

API

When we created our API based on API Platform framework we have done everything to offer API as easy as possible to use by developer. The most important features of our API:

  • All operations are grouped by shop owner, manager and admin context (three prefixes).
  • We create all endpoints implementing the REST principles and we are using http verbs (POST, GET, PUT, PATCH, DELETE).
  • Returned responses contain minimal information (developer should extend serialization if need more data).
  • Entire business logic is separated from API - if it necessary we dispatch command instead mixing API logic with business logic.
{% endblock %}