Size: a a a

2021 July 01

Л

Лев in symfony
я не хочу просто чтобы в другом модуле чел мог написать в хинте дто из левого и зарезолвить её
источник

Л

Лев in symfony
и не хочу в резолвере писать проверки на наследование чего-то от чего-то еще, или на подстроку в пути
источник

Л

Лев in symfony
то что всё можно сделать это не вопрос
источник

SP

Sergey Protko in symfony
не пиши
источник

SP

Sergey Protko in symfony
короч, у меня 700 роутов и может быть пара десятков ресолверов. И мне норм
источник

SP

Sergey Protko in symfony
и все красиво мэпится на dto и с валидацией и отдельно и если мне захочется могу с соблюдением open/close добавить новые штуки
источник

Л

Лев in symfony
а ты можешь в любом роуте "зарезолвить" что угодно если хинт напишешь?
источник

Ш

Шурик in symfony
deptrac?
источник

SP

Sergey Protko in symfony
да
источник

Л

Лев in symfony
а я вот не хочу чтобы я так мог
источник

SP

Sergey Protko in symfony
ну не "что угодно" а то что я разрешаю из архитектурных соображений
источник

SP

Sergey Protko in symfony
но у меня стандартный механизм мэппинга request -> dto который один на все
источник

Л

Лев in symfony
ну а решаешь ты это на уровне анализа?
источник

SP

Sergey Protko in symfony
если кому-то ну уж очень захочется может сделать кастомный нормалайзер - симфони такие вещи кэширует потому не будет 400 супортс вызывать
источник

SP

Sergey Protko in symfony
не, просто не будет работать если что-то не то засунешь
источник

SP

Sergey Protko in symfony
а границы - да, за счет анализа планирую (пока границ нет)
источник

SP

Sergey Protko in symfony
у меня определенные правила по структурированию проекта которые делают это весьма простым делом
источник

Л

Лев in symfony
ну тут далеко еще до правил
источник

Л

Лев in symfony
т.ч. вот думаю как лучше в перспективе подойти к этому
источник

SP

Sergey Protko in symfony
на кусочек моих драфтов

We are using package-by-feature strategy. The goal is to detect breaches of boundaries between different features better.

Let's consider a simple example:

App\Feature\PublicThing
App\Feature\Internal\InternalThing
App\Feature\Internal\InternalThing\WeNeedToGoDeeper

In this example, PublicThing is something other packages may import and use. It is the public interface of our package. Think about it this way - you want to integrate with a feature to quickly review the available integration option by simply looking at its top-level elements.

PublicThing may have dependencies on things that are one level lower in the hierarchy or first level of other packages:

# App\Feature\ItsPublicThing;
namespace App\Feature;

use App\AnotherFeature\ItsPublicThing; // allowed
use App\Feature\Internal\InternalThing; // allowed
use App\AnotherFeature\ItsInternals\InternalThing; // restricted
use App\Feature\Internal\InternalThing\WeNeedToGoDeeper; // highly discouraged, while not restricted
источник