How to properly design a Laravel application with an enterprise bias?

Question

Software design

We are planning to start a new project and would like to organize the structure taking into account the best practices.
If anyone can provide a real-world example of layering an application (DDD), I would be sincerely grateful.
I suppose that it is necessary to divide the application (app /) into Laravel-specific logic (controllers, middleware, etc.), Domain (interfaces, implementation of repositories):

taken from here

https://laravelinfo.com/struktura-prilozheniya-i-p...

How do you design your applications?
Thank you.

Answer 1

Take Symphony.
But seriously, why make a drill out of a screwdriver when it already exists. Do you think it will be faster? Do you think it will be cheaper? Laravel is great for its own, medium tasks, for "enterprise" take Symfony.

Answer 2

The main rule of a happy enterprise is not to drag methods and technologies in which there is no experience. If you have not worked on projects with DDD, did not make your own pet projects to try out the approach, then you do not need to train on large projects.
I have already seen 10 projects in the world of symphony and worked with three, everywhere attempts to make DDD ended with the incredible complexity of support, after which even Bitrix does not seem like a horror. 4 days and changes in 32 files to add sorting and filtering to the list... Probably, it is possible to write DDD correctly and with fast development and easy support, but I have not created such projects myself, I have not worked with others, I have not seen in as examples. Maintaining a 10 year old php4 legacy legacy with globals is much easier than any ddd stuff.

Answer 3

Now I will write a little arrogantly, but experience allows. For almost 20 years in development and about 15 in the web.
It must be understood that almost everyone who uses numerous frameworks does not understand what OOP is. And even more so, what is SOLID, etc.
And therefore, whatever they write, in the end turns into a poop with crutches.
Yes, then the project is heroically rewritten taking into account the changes (or even more often it dies) But, it still remains absolutely not extensible and not supported.
You need to take the Framework that was written taking into account certain paradigms and principles. Since there are not so many of these paradigms that have been sufficiently described and studied (in fact, there are 2.5 of them), then you can immediately focus on OOP + MVC (or MVP or MVVM) + SOLID
If the Framework violates any of this, then it The default cannot enable you to write a good, extensible application. And a good Framework, even novice programmers should instill the right approaches to development. Whatever you want, you don’t want, but hello world no longer turned into hell.
I’ll make a reservation right away that I “scored” on Frameworks a long time ago. There is one ideal one - this is Pyramid. And I evaluate any product according to the documentation. All the flaws and jambs are immediately visible there. I will write and look at the docks in parallel.
The first thing I see in this Framework is that most of the work of the framework components is tied to static calls. At this point, you can even stop. OOP, by and large, is not here. The essence of OOP is the use of objects. Here the class acts as a function namespace.
Since there is no OOP, then there is no whole theory and principles associated with it.
And since there is no theory under this Framework, then in 99% of cases we can say that something is correct on it, it is impossible to write.
Looking deeper reveals even more hell:
ActiveRecord.
Bad by default. It is very difficult to control data integrity with it. You need to come up with an abstraction layer where you will transactionally write all the data outside the business logic. The framework will not help you here. He will offer to do this in an action (controller). And then you will come across that when writing something more complicated than a blog, you will lose integrity. For the business logic and the work of the database will be in one method. Debugging will become more difficult, errors will multiply, and so on.
And it does not depend on programmers. The template itself provokes mistakes.
You don’t need to go far for examples , it’s already trash.
The more examples I look at, the more I don’t understand how to expand this whole thing. How to insert transparently through the entire project your own aspect solutions. For example RBAC. Or, if necessary, separate the logic of the application from the database and, when necessary, substitute the necessary implementation.
Or make all actions work within the client, but authorize by user (employee)
All this is proposed to be sewn up directly in the controllers, using protected or private methods.
Hang yourself. The complexity of the application will skyrocket.
Only when version 2 was released did I work with this miracle. The developers wrote it under the hype of dependency injection. Not only did they take not the best strategy for implementing the entire backbone of the framework, they also did it wrong.
They wrote a universal DI Container and put anything in it, using a string as an identifier.
Line, FUCK HER! Not an interface - a line!
And you know what it will backfire on? And the fact that when developing your application or the next bundle, you will be told that something is wrong in the container and you will die in the configuration settings. And all because, the approach: EVERYTHING through DIC is strictly imposed.
Extending this miracle will also cause you a lot of headaches. After all, often, you will work with classes that are waiting not for an interface, but for something from a container with the key "I_your_house_shatal".
The problem with introducing aspects through the entire framework does not disappear anywhere. But here for a different reason. The complexity of the platform components is over the top. Everything is written with a link to a specific implementation, but everything is received line by line from the DIC.
Because it is the central concept. Do not have another one.
But, in truth, there is an opportunity to blind something suitable.
If you take the symfony micro core, screw Doctrine, then you get something useful.
But the question arises. Why symfony at all, if you can take doctrine and write everything else of your own?
And here you will be right - there is no need.
The situation with Symfony in enterprise is very similar to the situation with Django. I have already seen about a dozen projects where the latter was taken for large applications. As a result, Django was left with horns and legs. All of it was rewritten.
The question is - and why? Just wasted a lot of time.
So, if you need a harsh enterprise. To write something big, with the possibility of expansion - take Pyramid and switch to python.
Nothing, even close to the pyramid, with the possibility of expansion, was not even close.

Answer 4

Symfony + Asked to check the code, what should I look at?

Answer 5

From personal experience, in short:
1. Do not use facades, only dependency injection , since automatic dependency resolution in Laravel is very powerful and convenient.
2. Don't use Eloquent, use Doctrine . *
3. Feel free to use asynchronous tasks . If desired, you can use them to implement a full-fledged CQRS.
* - Unless, of course, in your view, the essence of the business logic corresponds to the ORM model, because DDD involves separating the "domain layer" from the "persistence layer", although Doctrine allows you to mix them quite painlessly. In any case, Eloquent is the worst part of Laravel, and probably one of the worst implementations of ActiveRecord in PHP.

Answer 6

Use Laravel and don't worry. It is built on Symfony. If necessary, then using Doctrine instead of/together with Eloquent is possible.
You will spend more time learning Symfony and recruiting a team with its support. It's easier to use parts of it rather than being a smart snob to justify a high salary.
Laravel will allow you to quickly build a prototype. You will still have to change some critical parts. And it won't override the use of parts from Symfony.