Вопрос по прочитанному( Гексагональная архитектура)?

Question

[Abc Edc]

Недавно прочел habrahabr.ru/post/267125
Наконец то!
Давно хотел рашн едишн что нибудь найти по этому поводу!
Но я хочу один момент только уточнить я понимаю что все очень образно и хоть и названия паттернов перекликаются с laravel ,это можно где угодно использовать.
Но все же, в ларавел 5.1 вырезали ту самую командную шину из 5.0. И остался только JOB, но я так понимаю она нужна вообще только ради то чтобы хандлер использовал команду, но в job как раз handler вызовется сразу после конструктора. То есть если все эти 3 помощника объединить в один, как и сделали в 5.1 то это ведь даже лучше, правда?и еще пожалуйста один момент как быть скажем с обработкой таких форм когда создаются например 3 сущности одновременно? вся обработка разделятся грубо говоря на 4 job'a(command,handler,commandBus'a) ? то есть один запускает трансакцию другой создает основую сущность и затем две другие которые привяжутся затем к ней, или все же это в один обработчик ?

Answer 1

[Сергей Протько]

Вы не уловили сути идеи гексагоналок судя по всему. В частности вся соль гексагоналки заключается в том, что бы при помощи инверсии зависимости (не путать с контейнером зависимисти или IoC) отделить слои друг от друга. В частности отделить ваш код от кода фреймворка. Далее уже идут концепции из луковой архитектуры. Гексагоналка лишь описывает что должно быть на границах слоев.

То есть если все эти 3 помощника объединить в один, как и сделали в 5.1 то это ведь даже лучше, правда?

Нет, это просто упрощение. В целом это увеличивает зависимость вашего кода от кода фреймворка, а разделить по слоям сами юз кейсы и хэндлеры уже не выйдет.

и еще пожалуйста один момент как быть скажем с обработкой таких форм когда создаются например 3 сущности одновременно?

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

короч.. лучше не практикуйте пока гексагоналки, они вам пока не нужны. Все эти приемы приследуют определенную цель. И если у вас нет причин для этого, вроде... возможности быстро организовать еще один интерфейс к приложению, например черей MQ, или же у вас есть потребность в изоляции слоев для лучшей тестируемости оных... Или у вас сложная архитектура базы данных (что звучит маловероятно при использовании active record) и вы хотите применить CQRS что бы упростить работу с оными...

Вы должны четко понимать зачем это все нужно. Иначе есть шанс что вы архитектуре своего приложения сделаете только хуже. Просто так такого рода усложнения делать просто не целесообразно.

Comments

[Abc Edc]

Сергей Протько
Но мне нравится в этом все не только отделение от фреймвворка что да действительно для меня пока бесполезно, а отделение от типов контроллера будь то APIContoller, FormController или CIController

[Abc Edc]

Сергей Протько То есть то что контроллер всего лишь вызовет UseCase и соответственно скажем FormController и ApiController будут отличаться лишь ответом то ли редирект и Flash то ли просто ok 200, и data

[Abc Edc]

Сергей Протько то есть в этом случае как раз они и нужны ведь?

[Abc Edc]

Сергей Протько А не привязка к контейнеру а именно инверсия дает тоже абстракцию от фреймворка?

[Сергей Протько]

ГЛЕБ ГЛЕБОВ: ну так отделяйте. Для этого не нужно применять никаикх там гексагоналок и прочего. Для этого просто надо ввести сервисный слой и делать тонкие контроллеры. Вам этого может быть более чем достаточно.

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

По сути вся идея архитектуры сводится к инверсии зависимостей. И да, я искренне верю в то что все ООП только ради этого принципа и нужно. Это самая сильная сторона ОО подходов но почему-то мало кто это понимает.

[Abc Edc]

Сергей Протько Большое вам спасибо!

[Сергей Протько]

ГЛЕБ ГЛЕБОВ: наверное стоит привести пример раздувшегося технического долга что бы вы понимали когда это нужно все применять и когда не нужно.

Был проектик... вроде бы не большой, нацеленный на развлекательный сегмент рынка и все такое... то есть ничего не предвещало беды. Разработчики проекта были молоды и наинвы, поддались на маркетинг и взяли в качестве основной СУБД mongodb. То есть они изначально приняли какое-то решение связанное с инфраструктурой не особо понимая контекст приложения.

Шло время, приложение потихоньку разрабатывалось. И все бы ничего да только... из-за отсутствия изоляции повышалась связанность системы. То есть с каждым днем править код становилось все сложнее и сложнее. И в итоге оценки стэкхолдерам уходили все больше и больше.

И случилось страшное - внезапно оказалось что... люди взяли монгу и решили организовать связи на уровне ORM. То есть эмулировать внешние ключи и прочие вещи. В итоге система резко потеряла стабильность, начали появлться странные баги и прочие забавные вещи (при этом проект на 80% покрыт тестами).

Что мы имеем сегодня? Проект где отсутствие изоляции от инфраструктуры делает рефакторинг и устранение технического долга слишком дорогим предприятием. Так как мы не можем улучшить ситуацию на проекте в разумные сроки, стоимость внесения изменений все еще сильно завышается за счет высокой связанности кода.

Плохие решения принятые разработчиками в самом начале стоили где-то 30% бюджета проекта (то есть можно было этого избежать, но кто ж знал). Отсутствие изоляции не позволило быстро устранить проблему после обнаружения (плохость решений обнаружилась буквально через 2 месяца после старта разработки, нынче прошел год и люди там же где и были).

'nuff said. То есть с этим разделением все было бы круто, но и в крайности после этого тоже бросаться не надо, ибо из-за излишней изоляции всего от всего мы можем те же 30% бюджета спалить без особого профита.

[Abc Edc]

Сергей Протько Отличный пример! благодарю!

[Сергей Протько]

ГЛЕБ ГЛЕБОВ: контейнер зависимости это компонент который ресолвит зависимости. По сути это компонент который знает как собирать объекты.

инверсия зависимости это вот:



https://en.wikipedia.org/wiki/Dependency_inversion...

[Abc Edc]

Сергей Протько можем ли мы ее сравнивать с абстрактной фабрикой?

[Сергей Протько]

ГЛЕБ ГЛЕБОВ: нет. Абстрактная фабрика - это шаблон проектирования. Инверсия зависимости - принцип проектирования.

Шаблоны проектирования возникли не как результат каких-то изысканий, это просто данность. Они были всегда. И появились они как раз таки потому что люди пытались развязать систему, следуя тем самым принципам проектирования. Их потом просто собрали в 94-ом году их существующих проектов и дали им названия. То есть сначала реализация а потом теория. Потому то и был в 90-х холивары на тему надо ли использовать паттерны.

[Abc Edc]

Сергей Протько Сейчас действительно сделал вывод что гексагонал мне не нужен. Сервисный слой есть , его так и оставлю, инверсия тоже пока не нужна , у меня там в контейнере все, я даже самоRBAC туда засунул и в целом пока не приперло значит. Надеюсь до росту однажды)

Answer 2

[Алексей Уколов]

Но все же, в ларавел 5.1 вырезали ту самую командную шину из 5.0. И остался только JOB

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

Comments

[Abc Edc]

все термины только из статьи

[Алексей Уколов]

ГЛЕБ ГЛЕБОВ: Так в том и проблема, что термины вы увидели, а связать их вместе не можете (ну или объяснить). Архитектура приложений - это очень обширная тема, в которой еще и серебряной пули нет, поэтому QA-сайт не лучшее место, для обучения.

[Abc Edc]

Алексей Уколов Тогда можно лично к вам вопрос. Вы используете на сценарии использования отдельную(команду или джоб, хандлер да что угодно) для связи слоя предметной области ?

[Сергей Протько]

ГЛЕБ ГЛЕБОВ: сценарии использования (юз кейсы) это концепция и только. И да, я использую команды, но в контексте symfony2.

[Алексей Уколов]

Я тоже использую команды (то, что раньше называлось Commands, а теперь переименовано в Jobs). Но самое лучшее, думать о них не как о сценариях, а как о шагах этих сценариев. На каждый шаг - по команде. Разумеется, это только база - в каждом конкретном случае могут быть исключения, в зависимости от остальной архитектуры и бизнес-задач. Именно поэтому я и сказал, что Тостер - не лучшее место для такого левел-апа.
Самый полезный совет, который я могу дать - не заморачивайтесь слишком сильно за архитектуру. Архитектура - это инструмент. Нужно знать, какие инструменты существуют, чтобы в конкретной ситуации выбрать подходящий, но нет смысла покупать в квартиру бетономешалку, если у вас нет уверенности, что именно она вам нужна.