Pull to refresh

Comments 26

Сервис

Сервис — это мини приложение. Оно содержит:

один Роутер;
несколько Контроллеров;
несколько Views;
несколько Сервисов;
несколько Моделей.


Меня одного здесь что-то смущает?
И как View и Controller оказались в одном слое, если даже задачи у них принципиально разные.
И да, Clean architecture здесь вообще не при чем, нет в ней никаких царь-роутеров и царь-сервисов
И как View и Controller оказались в одном слое, если даже задачи у них принципиально разные.

Задачи разные да.
Они находятся в одном слое с точки зрения отдаления от пользователя.
1) архитектура кода не строится исходя из точки зрения отдаления от пользователя
2) пользователь view может увидеть, а контроллеры — нет.
3) слой — состоящий из принципиально разных элементов — или не слой, или дилетантская ошибка.
Буду честен — статья о классическом представлении Layered pattern, как проектировали приложения десятилетиями. Какую-нибудь толстую книгу о проектировании все-таки стоит прочесть, иначе вы правда не поймете, почему сейчас архитектуру, подобную вашей, пытаются избегать.

Ок, а какие на данный момент best practices?

Сложный вопрос. По мобилкам это MVVM и Clean (только настоящий, здесь никакого Clean Architecture нет)
Вопрос не в best practice, Layered pattern с монолитом обладает кучей недостатков, с которой в разной степени успешности борются другие архитектуры.
Выражение «KISS Architecture подходит для 80% проектов и обеспечивает плавную эволюцию проекта» подходит для любой архитектуры, и даже для ее отсутствия — все будет от пряморукости разработчика зависеть)
здесь никакого Clean Architecture нет

Все так. Тег выбран неправильно.
Этот «архитектурный» подход ближе всего к MVC с введением слоя Сервисов. Который в свою очередь вертикально разделяется на Query и Command.
Ну и фишка этого подхода в том, что Query или Command выполняет только одну задачу. Это позволяет не иметь конфликтов при разработке.

Собственно вся суть подхода описана в этом комменте.
Не уверен, что это поможет — при мерже, проблем, несомненно, будет меньше, а вот размазывание кода на много мелких сущностей с одним методом — хорошая заявка на «забыл внестив изменения во все необходимые классы»
Нельзя исключать такой возможности. Но в нашем случае результаты пока положительные.
Вообще не понятно, что здесь взято не из MVC.
Clean — не сложный, он то как раз гораздо понятнее и популярнее, чем описаные выше правила.
По хорошему, в MVC как раз подразумевается, что модель — это набор методов, фасад, прячущий за собой бинес-логику, инфраструктуру и т. п., а не какие-то объекты типа ActiveRecord, которіми контроллер оперирует.
Наверное да. Но на практике я в модели часто видел работу с БД. Да и сам так делал.
Работа с БД должна быть в модели в MVC (не путать с моделью DDD), но факт наличия БД в ней не должен протекать в контроллер и вью.
MVC — это паттерн UI слоя :)
> Каждый контроллер управляет только одной сущностью. Если нужно больше сущностей, то нужно добавить еще один контроллер.

Вот реально так? На примере абстрактного интернет-магазина: есть сущность «заказ», есть сущность «адрес доставки», есть сущность «строка заказа» (товар, количество) — и как минимум последняя не имеет никакого смысла вне первой. Зачем для неё отдельный контроллер?
Вот реально так? На примере абстрактного интернет-магазина: есть сущность «заказ», есть сущность «адрес доставки», есть сущность «строка заказа» (товар, количество) — и как минимум последняя не имеет никакого смысла вне первой. Зачем для неё отдельный контроллер?

Тут тоже наверное не вполне адекватно сформулировал.
Отдельный контроллер будет для сущности Заказ. И отдельный для сущности Товар.
Дальше дробить пожалй нет смысла.
В толстой книжке по DDD такие сущности называются агрегатами. Только ради общепринятого именования их уже стоит читать.
Лично я пишу бизнес логику в сервисах уже несколько лет. Но мне кажется, что такое чрезмерное разделение на один «invoke» — как то через чур. Скажите, какая причина такому делению?
При большом количестве разработчиков (больше 2-х) и длинных релизах очень много конфликторв было.
Сейчас конфликтов практически нет.
«У нас было много разработчиков и мало файлов, мы сделали много файлов и теперь все ок»
Вам не кажется что где-то что-то пошло не так на этапе распределения задач?
1. Не всегда возможно распределить задачи так как хочется. Нам приходится сталкиваться с суровой действительностью, в которой Заказчик может диктовать собственные правила.
2. В Clean Architecture есть Use Case, который как раз отвечает только за одну фунцию. По крайней мере именно так я понял.
1. Вам заказчик диктует, кто будет зададчку решать? Интересный феодализм
2. Скорее там речь о типе задач. И гарантируется он не просто «один класс — одна функция», а круговой моделью взаимодействия. Данная модель гарантирует, что презентер не стучитсяв модель или воркер например.
Заказчик дикутет количество задач, которые должны выполняться одновременно. А еще он диктует в какой последовательности и когда будут сдаваться те или иные фичи.
Бооооль.
Немного странно. По идее количество конфликтов в ситуации «много классов(файлов) с одним методом» и «один класс(файл) с много методов» должно быть лишь немного меньше, если по методам аналогично функциональность распределена. Или это фикс проблемы из разряда «давайте перейдём на микросервисы, чтобы дергали только фасад модуля, а не его напрямую»
Router=> Controller=> Service=> DAL
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.


Очень хочется, что бы разработчики понимали главное — нет «серебряной пули». Каждый проект уникален и требует индивидуального подхода. Конечно если ваша компания не занимается массовой разработкой бложиков на микросервисах :).

А книги читать надо, в том числе и про ДДД.
Sign up to leave a comment.

Articles