StringConcat - разработка без боли и сожалений

Можно ли смешивать стили в архитектуре?

Да, и иногда это даже необходимо.

Вот пример. Допустим, наше приложение решает две задачи:
– выполняет сложную бизнес-логику,
– и просто проксирует запросы в соседний сервис, проверяя авторизацию.

Иногда я встречал, как к прокси-части зачем-то применяют паттерны DDD — создают агрегаты, репозитории, слои, лишь бы просто передать данные. Это выглядит как человек в пиджаке, который пошел выносить мусор

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

Что с этим делать? Разделить приложение на две части, каждая со своим стилем:
• для бизнес-логики — использовать полноценную архитектуру, паттерны, валидацию, слои и всё такое;
• для прокси — ограничиться минимальным набором: контроллер и HTTP-клиент. Тут вообще напрашивается готовое решение, но иногда проще сделать внутри, учитывая что логика может появиться, хоть и очень простая.

Вывод: Стили можно (и нужно) сочетать, если это упрощает разработку. Главное — чтобы архитектура была практичной, а не просто нагромождение абстракций ради абстракций.

👍41🔥6❤5💯3

www.tgoop.com/stringconcat/339

2.84K viewsЕвгений, Jul 22 at 10:34

Можно ли смешивать стили в архитектуре?

Да, и иногда это даже необходимо.

Вот пример. Допустим, наше приложение решает две задачи:
– выполняет сложную бизнес-логику,
– и просто проксирует запросы в соседний сервис, проверяя авторизацию.

Иногда я встречал, как к прокси-части зачем-то применяют паттерны DDD — создают агрегаты, репозитории, слои, лишь бы просто передать данные. Это выглядит как человек в пиджаке, который пошел выносить мусор

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

Что с этим делать? Разделить приложение на две части, каждая со своим стилем:
• для бизнес-логики — использовать полноценную архитектуру, паттерны, валидацию, слои и всё такое;
• для прокси — ограничиться минимальным набором: контроллер и HTTP-клиент. Тут вообще напрашивается готовое решение, но иногда проще сделать внутри, учитывая что логика может появиться, хоть и очень простая.

Вывод: Стили можно (и нужно) сочетать, если это упрощает разработку. Главное — чтобы архитектура была практичной, а не просто нагромождение абстракций ради абстракций.

BY StringConcat - разработка без боли и сожалений