наркомания какая-то

или это типа юмор такой?

А что такого?

Приветствую. Ранее было интересное незаконченное обсуждение про товары и отзывы товаров. В частности чем будет являться отзыв -  самостоятельным агрегатом или сущностью внутри товара.
Продублирую, и еще свое накину:
1) Есть товар, у него 2 статуса проверенный/непроверенный в зависимости от того, проверены все отзывы или нет. В логике есть вещи, которые после опираются на этот статус.
2) Есть отзыв, который админ устанавливает проверен или нет.
3) Отзыв могут лайкать/дизалайкать.

Убираем вопросы гонки + sql операций, все делаем через сущности/агрегаты.  
Собственно отзыв  - это или 1) сущность внутри агрегата товара, или 2) Самостоятельный агрегат

1) Если сущность. Все api находится в агрегате товара. У товара появляются методы "Лайкнуть/Дилайкнуть комментарий", "Установить комментарий проверенным".  Все инкапсулировано в товаре, нет проблем с вычислением товар проверен или нет, просто запускается прогон всех комментариев при установке статуса "проверен" у одно из комментов. Не становится ли агрегеат товара слишком жирным? На него уже возлагается api по лайкам/дизлайкам комментария. Плюс прогон всех комментариев - ну такое себе, правда это уже другой вопрос, вопрос оптимизации.
2) Если отзыв - агрегат. У него свое api по лайкам/дизлайкам + установке статуса проверки.  Но тут тогда не понятно, как  устанавливать статус у товара, так как вычисления будут в сервисном слое и у товара будет метод типа "сделатьПроверенным". Т.е. товар никак не поддерживает свой инвариант.
3) Есть предположение, что нужно заводить какой-то отдельный агрегат "Отзывы товара" который не является маппингом таблиц БД. Который как раз на себя берет всю эту мороку с отзывами и инвариантами и устанавливает статус товара через БД. Т.е. у товара вообще не будет управление этим статусом, но у него будут данные о нем.  

Не понятно что будет более правильно в этом кейсе :) Или вообще по другому верно )

то есть просто купить то же зарядное или симку нельзя? Или это больше походит на "с этими товарами люди покупают" и предлагается просто заимпрувить (по сути упростить его спотанное желание чет купить) флоу покупки доп штук. Но с точки зрения системы, логистики и т.д. это все еще просто два товара.

В любом случае "телефон" про "зарядку" знать не обязан, зарядка не влияет на инварианты товара. Более того, мы когда добавляем товар в карзину - мы не с агрегатом товар работаем, мы работаем с его идентификатором (возможно даже версии товара).

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

Еще есть веселые вещи в духе "а если мы поменял правила - как это скажется на том что люди вот сейчас оформляют заказ, у них нарушаются правила резко?".

Агрегаты должны быть маленькими и по хорошему должны отвечать за те вещи которые ни при каких условиях не должны нарушаться. Даже на секундочку. Это например правила которые продиктованы не "хочу так" а законодательством (например в большинстве стран изменение цены после того как ты положил в карзину отдельно регламентировано).

Так что если коротко...

1. Я бы делал это отдельно.
2. Нет. Это может знать либо "товар-дополнение" либо "товар-дополнение" это что-то типа pivot связи между двумя товарами, оно же будет отвечать за хранение ограничений.

отзыв - самостоятельный агрегат так как у него свой цикл жизни.

Более того, если у тебя есть "статусы" и от статуса зависят возможные операции - возможно это не статус вовсе (только для UI) а просто разные агрегаты, один в конце своего цикла жизни создает новый с новым набором доступных операций.

самая большая проблема при проектировании систем - это введение accedental coupling. Это когда "ну вроде они связаны так пусть зависят друг от друга". Это большая часть всей связанности в системе обычно, достаточно редко есть объективные причины раздувать объекты какой-то логикой.

Благодарю. Соглашусь с утверждением  "товар-дополнение" в виде pivot связи. Мне это больше подходит в данном случае. А как оно будет называться в домене? Это же сугубо бдшная штука

Ну вот если "можно купить просто зарядку" то это просто продукт, а связь между двумя продуктами это уже Addition или как там твой бизнес это называет в общении с тобой.

Единый язык он как бы не просто так придуман и он единый не между разработчиками а между бизнесом и разработчиками

Хм, кейс что каждый новый статус =  новый агрегат довольно интересный, даже не думал о таком :)
Но это не решает вопрос про то, где будет тогда поддержка инварианта все отзывы подтверждены = 1 статус/одинАгрегат   , хоть один не подтвержден = 2 статус/другойАгрегат?

(упрощенно - просто глоссарий терминов который бизнес юзает)

а является ли это true invariant? Может быть и не надо этот инвариант пихать в агрегат. Что случится если у тебя на пару секунд это правило будет нарушено? И как ты его в целом можешь нарушить?

это часто больше про UX и про то как ты флоу юзера строишь что бы он в такую ситуацию не попадал или минимизируешь риски.

Что-то сложно разделить какие аниварианты true и нет ... По сути так можно все инварианты наружу вынести, привет анемик.

или просто много маленьких агрегатов и eventual consistency.

Получается что у нас pivot связь будет отдельной сущностью, которая связывает товар и дополнение. По сути ей не нужны внутренности товара и дополнения, только их id, если я правильно понимаю.

Так не понятно в этом кейсе, в каком месте должна быть логика по установке "статуса" товара. Третий агрегат?

просто если у тебя домен простой (например - профили юзера) то тебе может быть удобнее захерачить все через какой table gateway без всех этих мэппингов на объекты промежуточных.

Проблема с anemic model заключается в том что у нее стоимость обслуживания инфраструктуры такая же как и у не анемик (по сути твой ORM) только профита нет. Если ты за ORM и так не платишь то какая разница

все так