Comments 26
Сервис
Сервис — это мини приложение. Оно содержит:
один Роутер;
несколько Контроллеров;
несколько Views;
несколько Сервисов;
несколько Моделей.
Меня одного здесь что-то смущает?
И как View и Controller оказались в одном слое, если даже задачи у них принципиально разные.
И да, Clean architecture здесь вообще не при чем, нет в ней никаких царь-роутеров и царь-сервисов
И как View и Controller оказались в одном слое, если даже задачи у них принципиально разные.
Задачи разные да.
Они находятся в одном слое с точки зрения отдаления от пользователя.
2) пользователь view может увидеть, а контроллеры — нет.
3) слой — состоящий из принципиально разных элементов — или не слой, или дилетантская ошибка.
Буду честен — статья о классическом представлении Layered pattern, как проектировали приложения десятилетиями. Какую-нибудь толстую книгу о проектировании все-таки стоит прочесть, иначе вы правда не поймете, почему сейчас архитектуру, подобную вашей, пытаются избегать.
Ок, а какие на данный момент best practices?
Вопрос не в best practice, Layered pattern с монолитом обладает кучей недостатков, с которой в разной степени успешности борются другие архитектуры.
Выражение «KISS Architecture подходит для 80% проектов и обеспечивает плавную эволюцию проекта» подходит для любой архитектуры, и даже для ее отсутствия — все будет от пряморукости разработчика зависеть)
здесь никакого Clean Architecture нет
Все так. Тег выбран неправильно.
Этот «архитектурный» подход ближе всего к MVC с введением слоя Сервисов. Который в свою очередь вертикально разделяется на Query и Command.
Ну и фишка этого подхода в том, что Query или Command выполняет только одну задачу. Это позволяет не иметь конфликтов при разработке.
Собственно вся суть подхода описана в этом комменте.
Вот реально так? На примере абстрактного интернет-магазина: есть сущность «заказ», есть сущность «адрес доставки», есть сущность «строка заказа» (товар, количество) — и как минимум последняя не имеет никакого смысла вне первой. Зачем для неё отдельный контроллер?
Вот реально так? На примере абстрактного интернет-магазина: есть сущность «заказ», есть сущность «адрес доставки», есть сущность «строка заказа» (товар, количество) — и как минимум последняя не имеет никакого смысла вне первой. Зачем для неё отдельный контроллер?
Тут тоже наверное не вполне адекватно сформулировал.
Отдельный контроллер будет для сущности Заказ. И отдельный для сущности Товар.
Дальше дробить пожалй нет смысла.
Сейчас конфликтов практически нет.
Вам не кажется что где-то что-то пошло не так на этапе распределения задач?
2. В Clean Architecture есть Use Case, который как раз отвечает только за одну фунцию. По крайней мере именно так я понял.
2. Скорее там речь о типе задач. И гарантируется он не просто «один класс — одна функция», а круговой моделью взаимодействия. Данная модель гарантирует, что презентер не стучитсяв модель или воркер например.
It does not matter how you call it, it is just old good architecture
Пока отдельный компонент (напр. микросервис) достаточно мал и прост (условно говоря, если полезного кода в микросервисе до 500 строк — за вычетом стандартно-инфраструктурного кода вроде сетевого I/O, сериализации, логов/метрик), то ему вообще никакая явная архитектура не требуется. Может иметь смысл структурировать такие компоненты любым общепринятым в компании способом, просто чтобы быстрее находить нужный код в любом компоненте, но не более того, и чем меньше формальных требований предъявляет такая структура — тем лучше. Описанное в статье ближе всего именно к такому способу структурирования, хотя и избыточно раздутому, на мой взгляд.
А вот как только сложность этого компонента вырастает до состояния, когда отсутствие явной архитектуры начинает вызывать дискомфорт, пусть даже и минимальный — в этот момент стоит перевести этот компонент на Clean. Clean может казаться избыточной, но создание нескольких дополнительных интерфейсов и пара лишних копирований всех данных между почти идентичными структурами — небольшая цена за те возможности, которые мы получаем. Эта "избыточность" Clean в большей степени психологическая проблема, а не техническая — рефлекторно хочется избегать лишнего копирования из соображений производительности и написания однотипного кода, потому что обычно он создаёт неприятные проблемы — но в случае Clean этого не происходит.
А вообще всё это мелочи, вопросы архитектуры внутри компонентов в наши дни проработаны достаточно хорошо. Сложная часть в архитектуре начинается там, где нужно разделить весь проект на вышеупомянутые компоненты, чтобы большинство из них было достаточно небольшими, и чтобы связи между ними при этом оставались ясными и эффективными. И вот эта задача в статье вообще не упоминается. И большой комок грязи возникает не только из MVC, он вполне может получиться и из Clean, если не разделить большой проект на компоненты — просто в случае Clean это будет несколько больших комков грязи, тщательно разделённых интерфейсами. :)
Всё вышеописанное касается бэкенда. Для UI зачастую MVC/MVVM подойдёт лучше.
MVC хорошо подходит для маленьких приложений
Очень спорное утверждение. Ведь паттерн описывает то, как представление должно взаимодействовать с бизнес-логикой приложения и/или на оборот (в некоторых фокрах MVC).
DDD отличная архитектура, но ее никто не понимает.
ddd — это не архитектура, это подход (методология) для разработки доменной модели.
Clean Architecture отличная архитектура, но ее полная реализация имеет смысл для огромных приложений
Конечно писать обычный бложик с использованием «чистой архитектуры» не очень хорошая идея. Но Clean Architecture отлично подходит для отделения мух от котлет даже в небольших бизнес-приложениях.
MVC
View находится в одном слое с контроллером, отвечает за конечное отображение данных. Контроллер после получения данных из сервиса передает данные во View и возвращает View для отображения.
Каждый ваш микро-сервис это приложение, которое построено с использованием MVC-паттерна. От которого вы предлагаете отказаться выше:
Казалось бы тогда давайте возьмем MVC для микросервиса и на этом и остановимся. Но нет, такой велосипед нам не подходит.
Итого
На мой взгляд, KISS Architecture подходит для 80% проектов и обеспечивает плавную эволюцию проекта.
На мой взгляд ваша «KISS Architecture» — это обычная через чур раздробленная микросервисная архитектура каждый компонент которой построен на MVC. И не более того. Применять ее для простых приложения нет ни какого смысла — я с удовольствием сделаю выбор в пользу монолита и откажусь от кучи накладных расходов на тестирование и развертывание. А если применять вашу «архитектуру» к крупным приложениям, то вы просто погрязнете в лавине ваших моделек-контейнеров.
Этот архитектурный подход будет понятен всем разработчикам и для его применения на практике не нужно читать толстенные книги про DDD.
Очень хочется, что бы разработчики понимали главное — нет «серебряной пули». Каждый проект уникален и требует индивидуального подхода. Конечно если ваша компания не занимается массовой разработкой бложиков на микросервисах :).
А книги читать надо, в том числе и про ДДД.
KISS Architecture. От микросервиса до монолита