shopware architecture - additional content#2147
shopware architecture - additional content#2147Su (sushmangupta) wants to merge 1 commit intomainfrom
Conversation
|
|
||
| Shopware organizes the Core around commerce-related domains rather than technical layers. Examples include: | ||
|
|
||
| * Products |
There was a problem hiding this comment.
those are not the real domains like we have them in the code 🤔
more like:
Checkout -> Order
-> Customer
Content -> Product
-> Category
|
|
||
| Message queues allow heavy operations to run outside the request lifecycle. | ||
|
|
||
| ## Interaction with other components |
There was a problem hiding this comment.
was kinda already said above 🤔
| High-level architectural overview of Shopware’s core system layers and supporting infrastructure. | ||
|
|
||
| ```mermaid | ||
| flowchart TB |
There was a problem hiding this comment.
unfortunately this does not render, so I could not verify this
| * Custom API routes | ||
| * Dependency injection configuration | ||
|
|
||
| Plugins integrate into the system without modifying core code, enabling safe upgrades and customization. |
There was a problem hiding this comment.
"enabling safe upgrades and customization"
We wish it would be like this, but it isn't. Otherwise there would be way less issues on GitHub.
| Extensibility is a fundamental design principle of Shopware. The Core provides multiple extension mechanisms: | ||
|
|
||
| * Symfony event system | ||
| * Service decoration |
There was a problem hiding this comment.
Service decoration is done via DI configuration. So this is partially redundant with "Dependency injection configuration". Without the DI configuration, the decorator would just be a child class.
|
|
||
| The Core exposes functionality through two primary APIs: | ||
|
|
||
| * **Store API** — Public-facing API used by storefront applications and headless frontends. It supports anonymous access and customer-authenticated requests depending on the endpoint. |
There was a problem hiding this comment.
Frontends arent headless. "Headless" is refering to the sytem which does not have a pre-defined representation layer for human interaction. As far as I know it originated from "headless computers", so computers without monitor, mouse and keyboard.
So "headless frontends" is somewhat contradictory. It may be used because of colloquial sloppiness but it's not accurate.
|
|
||
| ## APIs and communication | ||
|
|
||
| The Core exposes functionality through two primary APIs: |
There was a problem hiding this comment.
That is only partially true. These are the HTTP APIs. API is a much broader term and describes the overall interaction surface with any system via any communication method. A plugin or an app is also using the Shopware Core API with events or service decoration. No web request involved.
| * Indexing and search updates | ||
| * Scheduled tasks | ||
| * Email sending | ||
| * Integration workflows |
There was a problem hiding this comment.
Is this refering to the flow building?
|
|
||
| The Core serves as the foundation for: | ||
|
|
||
| * **Storefront** — Uses the Store API and domain services to render customer-facing pages. |
There was a problem hiding this comment.
The Storefront doesn't use the Store API (there might be edge cases, but at least I can't remember any). https://github.com/shopware/frontends uses the Store API. The Storefront accesses the PHP API of the core. It's basically a plugin.
There was a problem hiding this comment.
the Storefront uses the store-api route classes as services. the storefront is not a plugin, but more a "bundle" in Symfony terms speaking
|
|
||
| Conceptually, the Core sits at the center of the platform architecture. While the Storefront and Administration provide user interfaces, the Core exposes functionality through structured APIs and services. All business logic, domain modeling, and system integrations are implemented within the Core to ensure consistency across different presentation layers. | ||
|
|
||
| The Core is built on Symfony and follows modern backend design principles such as dependency injection, domain-driven organization, and event-based extensibility. |
There was a problem hiding this comment.
"Modern" is an arbitrary and ambigious term in Software Engineering. Like "legacy".
|
|
||
| ## Data abstraction layer (DAL) | ||
|
|
||
| The Data Abstraction Layer (DAL) provides a consistent way to access and manipulate database entities. Instead of working directly with database queries, developers interact with repositories and entity definitions. |
There was a problem hiding this comment.
This does not always apply. There are integration points like indexers where DBAL or SQL usage is explicitly advised because DAL events might cause an infinite loop there. There are other examples where DBAL or SQL usage is fine.
I think one of the more interesting points is that we do not use an ORM which is more common (debatable but ORM is definitly more established than DAL).
There was a problem hiding this comment.
while this is true, I am not sure, if we should put that into the docs 🙂 the way to go for 3rd party devs is using the DAL.
There was a problem hiding this comment.
It is recommended to work directly with the Connection since the event is dispatched in the context of an indexer. If we would use the Data Abstraction Layer (DAL) for writing changes to the database, the indexer would be triggered again, because it listens for EntityWrittenContainerEvent events. This would lead to an infinite loop. Using the Connection directly prevents the DAL from dispatching entity written events. Also the performance of plain sql is much higher, which is very important for indexers in general.
It is in the official documentation as a recommendation and also in the example there.
There was a problem hiding this comment.
yes, and it is okay to have that in the docs for that specific use-case. but I would not suggest to put into such general architectural overview
3 participants
No description provided.