What is the main pattern to use for marketplace in laravel?

Question

Web development

We are writing a trading platform like Market Place. Where, unlike an online store, it is allowed to register suppliers and place their goods. The work of our operators is to ensure that they somehow identify the same products from different suppliers and combine them into a common entity so that there is one product and several trade offers.

Now a Symfony programmer has joined our team and suggests introducing the CQRS pattern and writing in Symfony Style.
I looked at Porto earlier. Dmitry Afanasiev spoke well and convincingly about him.
Well, I looked closely at ddd.

How can we develop the project better? It is also necessary to take into account that the code must be readable and that we take any junior to the team and that he will figure it out from the very first day. If we write in Symfony Style, then beginners will not figure it out.

What is the best way to resolve the situation?

I think that it is better to declare the approach and write documentation about how it works and how new methods are added to it so that any proger can already act according to this instruction, otherwise it will turn out that the new developer wants to leave the project, and there is no longer Laravel, but the code, which is hard to read but leads to the correct architecture.

Answer 1

> Now a Symfony programmer has joined our team and suggests introducing the CQRS pattern and writing in Symfony Style.
> How best to resolve the situation?
Everything is mixed up, styles, programmers, some kind of "patterns". You are trying to solve a lot of unrelated development organization issues by grasping different terms that you hear about, but about which you still have a vague idea. Terms from different areas, moreover.
If your goal is to first of all gain experience through the project, try different things, cool down at work and experiment - keep it up !
If the goal is to deliver the project within a reasonable time and budget - write as you know how and know, gradually increasing your level, studying new approaches, preferably not on the main project, but at your leisure, or at least in non-critical parts of it. Otherwise, with such zeal, you will have to rewrite the entire project to a new paradigm / framework / "pattern" (sorry fowler) every month.
Hire or designate someone to be the lead and let them decide what to use and what not to use. But not every new incoming developer. With all due respect to Symphony and not love to Laravel.
> it is better to declare the approach and write documentation about how it works and how new methods are added to it
The problem is that if the project lives, all this will change many times, under new requirements, refactoring, fixes. And the documentation will lie. It's best to keep the code as simple as possible. To look at it was easy to understand. R. Martin and S. McConnell have a lot of discussion on this topic.
I use tests as a fixation of how the code works, I try to avoid documentation altogether.
I did not really understand the passage about the new developer leaving the project, you are confused. In general, code review is a common practice so that changes in the code are not a surprise for the team.
> code that is hard to read but leads to the correct architecture.
If you sacrifice the simplicity of the code, this will definitely not lead you to the "correct" architecture. The more difficult it is to understand the code, the more likely it is to misunderstand it, and add a new one not as it should be.
What does "correct architecture" mean for a start should be defined. In fact, it does not exist, it is the Grail. I would say that there is suitable and not suitable, excessive for the requirements of the project and lagging behind them, hindering development. According to what is voiced, Laravel, with its generally accepted approaches, should be enough for your eyes for a long time. That's when it stops being enough, at least you will solve a real problem, not an invented one. And you will find the architecture that fits better than the original one, to the new realities.
Try to think in such categories. If instead of sawing your marketplace (i.e. the necessary features), you look for the Grail, the success of the project will not shine.