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

В то же время ни Order, ни Payment не могут работать без Cart

То есть у вас возникает циклическая зависимость Order и Cart? я так понимаю?

Вообще Order, Cart и Payment можно объеденить в один модуль, который задает базовые интерфейсы + тыща модулей с реализацией интерфейсов. Типа CardPayment и т.д. Словом нужно избавляться от циклических зависимостей и думать о кейсах когда с чем будет работать. Скажем Cart без Order не имеет смысла, а вот Order без Payment - имеет.

Или же тема оформления не поддерживает нужный модуль.

Хорошая идея - тема должна содержать метаданные о том какие модули оно поддерживает а какие нет. + идея с виджетами.

Возможно ли это? Если не полная, то хотя бы слабая зависимость модулей друг от друга?

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

Стоит ли оно того?

Увы вы один не сможете написать и поддерживать такую систему. Многие пытались и даже есть парочка неплохих вариантов ( sylius.org например ), но в одиночку за приемлимое время - маловероятно.

Какие есть пути уменьшения зависимости модулей друг от друга?

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

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

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

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

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

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

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

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

шаблон Registry.

p.s. Зачем вам монга то?

Для начала разберитесь с принципами объектно-ориентированного и функционального программирования. Штуки вроде "почему высокая связанность кода это плохо, зачем нужны MVC и т.д."

Паралельно можете поразбираться с типичными шаблонами проектирования под js: largescalejs.ru

Ну и еще - ES2015, активное использование модулей и штук вроде jspm/webpack для сборки. По сути все проблемы в js - кривое управление зависимостями (вся соль ООП в принципе состоит в инверсии зависимостей, функциональные подходы делают все еще лучше). Сейчас ситуация с этим всем намного лучше чем была скажем еще года 4 назад.

Опять же, когда речь идет о реально больших проектах, следует перестать писать на каждый чих свой велосипед. Нужна библиотека для организации маршрутизации - берем готовую. Нужно работать с датами - берем moment.js и т.д. Сборщики вроде того же jspm умеют выдерать из популярных библиотек то что можно (если можно так сделать, скажем с angular2 выдрать только нужные модули можно. а вот с angular1 нет).

Фон Нейман как бэ в принстоне преподавал. Просто намекаю... Гарвардская - развитие архитектуры фон-нэймана призванная уменьшить влияния "горлышка" первого.

читайте вики, там все более мение по делу.

Откройте для себя путь DDD. Доменная модель на все приложение одна и не привязана к модулям фреймворкам и вообще. Правда в контексте Yii сделать чистые модели не получится, php все же не ruby.