-
Notifications
You must be signed in to change notification settings - Fork 478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document CQRS #232
Document CQRS #232
Conversation
Nice introduction! For me the docs should answer some questions of the PrestaShop developers:
WDYT? /c @eternoendless |
In another subsection, yes 😉it's 2 subtopics: what is X and how we implement X in PrestaShop. Like "what is Dependency Injection" and "How Symfony implements Dependency Injection with the Symfony Container"
Looks like the right place to me 👍 |
CQRS stands for _Command Query Responsibility Segregation_. In brief, the CQRS pattern suggests to separate "write" and "read" models, which it refers to as Commands and Queries. | ||
|
||
## Why using CQRS in PrestaShop? | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why we need to keep core and why we need to isolate it ?
Something like
"We are currently migrating PrestaShop Back Office to Symfony but the new Controllers, Templates and classes dedicated to the BO are still using the Core classes of PrestaShop used by the previous BO. One day, we will remove this Core too. Until that day, we need to allo the new BO to access these classes and data while keeping a clear border between these 2 areas of code as one is expected to remain and the other one to disappear."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think this commit b908ef4 explains it?
Commands and Queries allow us to isolate the controllers from the data source, which can be later replaced by something else while leaving behind a nice API. | ||
|
||
This implementation proposes a "top-down" design, which inverses the classic data-driven design. It starts on a page and the actions performed in it, and then trickles down layer by layer, finishing on the data layer. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be nice to have a schema here. This schema would compare old and new architecture.
In old architecture we would see the browser sending HTTP requests to a big bunch of code which would contain Controllers calling directly core classes. Like:
browser ==(send HTTP requests)==> controller ==(calls)==> core
In new architecture, we would show the clear separation of the bus
browser ==(send HTTP requests)==> SF controller =(dispatchs Queries and Commands)=> Bus routing =(Handler handles the Command/Query)=> Adapter Handler ==(calls)==> core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, I've tried to do so in b908ef4 commit, could you check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Co-Authored-By: sarjon <jonusas.sarunas@gmail.com>
Co-Authored-By: sarjon <jonusas.sarunas@gmail.com>
Thank you @sarjon |
I referred to PrestaShop/PrestaShop#9370 and found that explanation well written, so I basically ended up copying @eternoendless work with some minor changes to it. 😈
I have a few questions:
Architecture
good section for this article? I was also thinking aboutArchitecture/Migration Guide
, but it feels a bit wrong.