кохижн - внутренняя, coupling - внешняя

А внутренняя или внешняя связанность или связность?)

А внутренняя или внешняя связанность или связность?)

> Можно начать говорить об архитектуре yii... Чистота кода зависит от программиста, а средств yii хватает для всего Вот из-за такого непонимания объекта спора и вытекают все "бла-бла-бла". Давайте всё-таки разделять: Чистота и удобство *своего* кода зависит от программиста. Чистота и удобство *кода фреймворка* не зависит от программиста. Со своим кодом проблем нет. Все "затыки" происходят при попытках взаимодействия с кодом самого Yii.

Профит использования репозиториев и других вещей - в инкапсуляции. Если претензии именно к названию "Repository поверх AR", то замените его на какой-нибудь "EntityManager поверх AR" и все недопонимания отпадут. В данном случае репозиторий делегирует сохранение в ActiveRecord. Но простым переписыванием сущности и репозитория строка $order->save() в репозитории за один час превращается в $this->em->persist($order) или $this->pdo->execute('INSERT ...'). Без переписывания сотен контроллеров, тестов и хэндлеров.

Взял. $item->getId() - это и есть хэш.

Это конструктор строки CartItem, записывающий каунтер и модификатор. Ничего не теряется.

А то, когда говоришь себе на русском начинаешь путаться

у меня чуть другой вопрос - почему нельзя в рамках одного проекта использовать и DM (для write части) и AR (для read части оно хорошо подходит)

А можно называть cohesion, как SRP

Зацепление, как то стрёмно звучит:))

А можно называть cohesion, как SRP

я насчитал тут 4 зоны ответственности + нарушение OCP

когезия и связанность?)

Связанность то и другое, а когезия звучит прикольно, только людям придется переспрашивать:)

Ну я остановился на варианте, внутренняя и внешняя связанность

я в опенсорсы пошёл бы только за то, чтоб Протко отхлестал мои ооп'ы

ты же понимаешь что люди не делают одно и то же

Изначально без контекстов есть просто сущность User и в ней собраны ответственности аутентификации, покупателя и т.п. В большом проекте приходим к нарушению SRP и получению God Object с сотнями методов и связей. Усложняется класс и его тестирование. Для борьбы с этим приходит на помощь разбиение на контекты как в указанной статье. Агрегат User для работы в соответствующих контекстах как "пользователь" в процессах аторизации, "покупатель" в процессах магазина, "участник форума" и "автор блога" мы разбиваем на отдельные сущности User, Buyer, Author и Member и перемещаем в них только нужные им данные и поведение и т.п.

а можно строчку где переключение происходит?

это разные классы

они никак между собой не пересекаются

ну вот как-то они же пересекаются

не ну могут, но по идее не должны

UserBuyerModel:getById($user->getId()) ? :)

так, "магазин" это не контекст, это контекстище

Это так кажется в текущем масштабе. Если рядом с таким "Магазином" появится такой же разделище "Склад" со складским учётом и раздел "Бухгалтерия" с актами и налогами, то тогда и будет смысл выделять контексты для фигурирования товара в номенклатуре и накладных.