Good symfony app architecture?

Question

symfony

What does "Well designed application using Symfony2" mean?
My opinion is that this is an application in which there is a necessary service for receiving or manipulating any data, which, in turn, is organically combined with other container services.
And you, {{ user.name }}, what do you think?
UPD: There was (along the way) another question. And what then means "Well organized application service layer"?
UPD2: from uv-x keltanas answers and Nikolas Lindemann, no matter how ambiguously it follows that everything is a good application has a layer of work with data directly (a doctrine, for example, which supplies data to models), but since the application in the topmost layer can have different interfaces with the outside world, then the logic of the it is better to hide applications in one more layer between them. This layer (service?) will interact with the layer of work with data on requests from interfaces (top layer), thereby providing a single logic for the application as a whole. But you should not assign data saving operations to the logic layer, but only manipulations (actually, the implementation of the logic itself)
UPD3: It has been noticed that many people look at the architecture in their own way :) For some, a good architecture is the convenience with which you can cover the code and functionality with tests; for some, it is the ability to make changes without compromising the surrounding components. Maybe from this we should conclude that a good architecture is one that consists of independent, but strongly connected components?
UPD4: ADR ( https://habrahabr.ru/post/260769/).
UPD5: SOLID

Answer 1

A good architecture is a very understandable architecture, when there are logical and understandable means for each type of task. When an application is built in this way, it can be both tested and modified / extended. If you need to add a new class, then in a good architecture it is clear where you need to add it.
There are not many types of tasks in total:
1) storing application data - model. The model doesn't need to know anything about the database.
2) a layer of access to a DB - a repository. All work with the database is here, and everything related to one entity is in the repository of this entity. If you need the interaction of several entities, then, most likely, the repository of one of the entities will not work, this task will go to the service.
3) business logic - services. Services are able to receive data (models) by accessing repositories or, better, other services (service).
4) service tasks - services. For example, data caching is implemented in a special service.
5) data display - templates. All html is only in the template, as well as the display logic is also in it (list output, some filters)
6) preparation of data for display - controller. The user's request comes to the controller, while the controller accesses the service (or in a simple case, the repository) for data. Perhaps, to process the request, you need to get data from several services / repositories, but rather, the right service itself will prepare all the data for the request.
It turns out that the controller calls a service that will provide ready-made data, and will be very simple - "thin". The main code responsible for the operation of application tasks is in services. The same service will often be called from different controllers. Working with the database is not in the service and certainly not in the controller, this requires a repository.
If the database structure changes, then in a good architecture, only the repository will have to be changed, but not the services / controllers. On the other hand, changing the database schema is most often associated with new features, so you have to add a new service or change an existing one.
The model, on the other hand, does not know how much - to display its data, possibly in different formats (the data returned by the model does not have to match the fields of the entity - see the example in the keltanas comment in the answerVladimir Balin ).
Models, repositories, controllers, templates are usually located in special project folders. But services can be located in completely different project folders created specifically for them. As an example, caching services can be placed in the Persistance folder - a separate service for getting entities and separate services for getting aggregated data (received from different entities). When you change the caching method, only the services related to caching will change, not the rest of the project.
It turns out that controllers are "thin", models are "thin", and repositories are much thicker. Services are also "thick", but it's good to break them into separate services so that all the project logic is not in one class, and then each service is no longer so "thick".
PS I wrote that the model should not know anything about the database, it turns out that it is wrong to use annotations to map entity fields to table fields. After answering this question, I will most likely reconsider my views on @ORM annotations in models.

Answer 2

If the whole application can be covered with unit tests without problems, if you have thin controllers and rather thin services and fat models, if you follow the principles of SOLID, etc... then you have a code that is very easy to maintain and extend. For more complex projects, there are all kinds of DDD, CQRS, there is a hexagonal architecture ...
In short, it all comes down to such a parameter as maintainability.
https://github.com/phptodayorg/php-must-watch#arch...
updated
if interested, there is an example of a "good" architecture (well, or the basis for it), or at least an interesting one:
https://github. com/qandidate-labs/broadway
Of course, this example is not suitable for all subject areas, but as one of the "see how people do" options, I think it's good.

Answer 3

Judging from the discussion, it is clear that the application should be, at a minimum, well-tested and ready for easy extension and / or changes. And this is achieved by storing business logic in services that are connected to the container, but not in models, because the database layer can (potentially) change.
We conclude: thin controllers, a thick service layer and thin (or not so) models.
Everything seems to be correct?

Answer 4

Probably many do not want to understand why a service is needed at all, what is its main goal ?! Most people equate it as another kind of abstract layer, where you can fence off some, and there are times when the entire application logic, that is, the model and the service, is essentially the same, and give preference to the service. Apparently, as much as I heard and read, concluding that this is argued by the fact that it just sounds cooler: this is a SERVICE, and not some kind of model, it means something worthwhile, and in the eyes of colleagues, or our fallen users this is considered and regarded as superiority ... In general, there is nothing good from this!
Back to the topic itself, a service is just some functionality that can work at the level of the entire application. Of course, at the level of the entire application, you want to make not only some harmless functionality, but some kind of service, but you need to do this wisely, because this is not the main task of the service, as a result of which performance may fall.
To the author's question:
1. Using the MVC design pattern.
2. Design on a service-oriented architecture.
3. Designing on an event-oriented architecture. In any case, it is necessary to proceed from the task, and select the best tools for solving it.
There are many more options, but there is no sense and desire to copy-paste, it is enough to search for "software architecture" in the search engine.