Здравствуйте, Shmj, Вы писали:

S>Для затравки: https://habr.com/ru/articles/903426/

S>Вот сейчас как принято:

S>1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас.
S>2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее.
S>3. Слой Domain — уже идеальное представление для нас.
S>4. Ну и само отображение на форме.

S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.

Самое важное разделение — отделение домена от инфраструктуры. Инфраструктурные слои поддерживают контракты. Входные слои (контроллеры) поддерживает контракт с клиентами приложения (API приложения). А выходные слои (адаптеры) поддерживают (инкапсулируют) API провайдеров, с которыми работают приложение.

Имея такое разделение по слоям очень легко отвечать разные вопросы: Какие изменения нужно сделать, если входной контракт или контракт провайдера поменяется? Как повлияет добавление/удаление поля из домена на входные и выходные контракты. Это сильно помогает как при оценке доработок, так и при самих доработках.

Изменений несколько, потому что одно изменение делается в домене, а остальные изменения — в контрактах. И это отличный повод задуматься про это поле в этом конкретном контракте — нужно ли это поле, в каком оно формате, как обеспечить совместимость и т.п. Как уже сказали, работа с контрактами намного сложнее написания самого кода, т.к. требует согласования людей. Изменение контрактов — боль.

Также разделение на слои позволяет выделить контракты внутри приложения — интерфейсы между доменом и инфрой. Это позволяет разделить приложения на относительно простые куски, а также легко решать много полезных задач. Например, изменять схему БД (это происходит намного чаще, чем замена БД, о которой часто говорят). Или добавить кэша к БД (или к сервисам). Ну и, конечно же, все эти мидлвари, логи, трейсы, метрики, рейт-лимитеры, предохранители и прочие штуки, которые прекрасно живут в инфра слое, на загрязняя важный доменный код

Так что исправление в нескольких местах совсем небольшая плата за большое количество преимуществ.

Здравствуйте, Shmj, Вы писали:

S>Для затравки: https://habr.com/ru/articles/903426/

S>Вот сейчас как принято:

S>1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас.
S>2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее.
S>3. Слой Domain — уже идеальное представление для нас.
S>4. Ну и само отображение на форме.

S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.

Самое важное разделение — отделение домена от инфраструктуры. Инфраструктурные слои поддерживают контракты. Входные слои (контроллеры) поддерживает контракт с клиентами приложения (API приложения). А выходные слои (адаптеры) поддерживают (инкапсулируют) API провайдеров, с которыми работают приложение.

Имея такое разделение по слоям очень легко отвечать разные вопросы: Какие изменения нужно сделать, если входной контракт или контракт провайдера поменяется? Как повлияет добавление/удаление поля из домена на входные и выходные контракты. Это сильно помогает как при оценке доработок, так и при самих доработках.

Изменений несколько, потому что одно изменение делается в домене, а остальные изменения — в контрактах. И это отличный повод задуматься про это поле в этом конкретном контракте — нужно ли это поле, в каком оно формате, как обеспечить совместимость и т.п. Как уже сказали, работа с контрактами намного сложнее написания самого кода, т.к. требует согласования людей. Изменение контрактов — боль.

Также разделение на слои позволяет выделить контракты внутри приложения — интерфейсы между доменом и инфрой. Это позволяет разделить приложения на относительно простые куски, а также легко решать много полезных задач. Например, изменять схему БД (это происходит намного чаще, чем замена БД, о которой часто говорят). Или добавить кэша к БД (или к сервисам). Ну и, конечно же, все эти мидлвари, логи, трейсы, метрики, рейт-лимитеры, предохранители и прочие штуки, которые прекрасно живут в инфра слое, на загрязняя важный доменный код

Так что исправление в нескольких местах совсем небольшая плата за большое количество преимуществ.

P.S. Не сразу заметил, что это раздел священные войны. Не стал бы расписывать