P.s. не понятно что у тебя там за агрегаты на чтение для принятия решений извне - вот там скорее всего чёт не то

А можете пожалуйста привести пример кейса когда прям event sourcing - это лучшее/самое подходящее решение?

Когда что происходит сильно важнее текущего стэйта (например нужно много экспериментировать с моделью или требования плохо определены). У Грега Янга были примеры ситуаций когда например возникают ситуации когда что произошло и когда понятно а вот как интерпретировать это зависит от ситуации. Например "секретный холд на счёт наложенный ФБР"

В целом основная мысль - интерпретация стрима ивентов* и принятие решений когда часто меняется и нет лучшего варианта. Всякие трейдинги представь

Не совсем из вне.
Конфигурация лежит в одно контексте с коментами.

Хочу гист :(

спасибо

+, если не сложно.
Очень хочется глянуть какие доклады стоит пересматривать

Поток телеметрии с устройств (например с автомобиля) когда важно не только текущее состояние, но и все события, все изменения состояний

Добрый день. Подскажите пожалуйста, второй день ломаю голову себе.
Пытаюсь сделать интернет магазин вещей с помощью DDD в качестве первого проекта.
Товары содержат всю информации: цвет (если доступен), размер.
Корзина у меня получилась агрегатом.
В корзину мы можем добавить товары, удалить, изменять его количество (уменьшать, увеличивать)
Например, где-то внутри корзины должен быть метод
class Cart {
  ....
  function editCartItemSize (CartItemId, Size) {
        cartItem = this.cartItems->get(CartItemId);
        cartItem->setSize(Size)
  }
  ...
}

Правильно ли, что мы должны через корзину редактировать внутреннюю информацию о выбранном товаре? Я согласен, что мы должны редактировать количество через корзину, но вот вся внутренняя информация - вот вопрос. Что, если будет несколько типов товаров? Допустим добавится техника, там внутренняя информация будет уже другая (допустим для телефонов - количество памяти и цвет, для процессоров - частота и модель и т.д.). В таком подходе у нас корзина разростется до больших размеров для каждого типа товара:
function editProcessorModel(CartItemId, model)
function editPhoneMemory(CartItemId, memoryId)

Мне кажется для такого типа вопросов желательно для начала понимать что ты делаешь, прочитать хоть одну из базовых книг Вернона или Эванса, посмотреть несколько докладов общепринятых и тд. Вопрос стоит как «слышал звон, но не знаю где он»

Агрегаты и Энтити это не то же самое, как замечали выше агрегаты сохраняют правила между несколькими энтити, но если у энтити есть какие-то вообще отдельные обособленные пропертя то их можно менять в другом процессе. Даже в условном «круде»

Если условный phoneMemory никак не влияет вообще на карт, то зачем он там должен быть? Или если больше памяти - больше цена? Может проблема в том, что уже должна быть другая модель продукта, то есть другое энтри допустим в каталоге? Другой айдишник если 64 или 128гб к примеру

Вопрос про Qt Model/View. Если рассматривать с точки зрения чистой архитектуры дяди Боба, то где в ней находится Model?

Спасибо за ответ. Пока прочитал только Вернона, хотел попробовать свои силы.
То, что энтити и агрегаты разное - да, знаю. Да, меняется цена в зависимости от выбранного цвета/размера.
С айдишниками не хочу делать, ибо получается слишком просто тогда, как во всех типичных примерах корзины, которых очень много.

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

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

Допустим тут. Не думаю, что айдишник футболки меняется в зависимости от размера и цвета, что black+xl=1, black+3x=2 и т.д.

ProductId возможно и нет, но modelId или articleId 100% да.

В любом случае это не прерогатива корзины, это условный product page вообще

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

Хочется сложно? Сделать все виды тестов для твоего приложения, от юнитов, до интеграционных, контрактных, мутационных, е2е автоматизированных на браузерстаке каком-то и с деплойментом тест энвайронмента с полной контролируемой инфрой - вот это будет show off :)

Просто в том смысле, что я могу загуглить "ddd shopping cart" с кучей однотипных репозиториев, хочется сделать по-другому.

DDD bank account :)

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

Итак. Вы решили сделать что-то при помощи DDD. Вот ошибки с которыми вы сталкнетесь:

1. излишний акцент на "сущности" и недостаточное понимание что такое "bounded context". С этим прям буквально все сталкиваются. Винить в этом никого не надо (кроме Эванса за то что так акценты в книге расставил). Проблема тут - поскольку фокус внимания смещен на сущности и анализ крутится вокруг них, неизбежно будут появляться сущности типа "карзина", "заказ", "покупатель" и т.д. Проблема в том что все эти сущности существуют больше чем в одном контексте и очень быстро разбиение на модули не будет соблюдать SRP. Как следствие повышается связанность, снижается cohesion и такую систему становится достаточно дорого поддерживать (потому что сложность взаимосвязей элементов бизнес логики ничем не контролируется).

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

2. Вы попали в заблуждение "DDD это ответ на вопросы как писать код". Распространенная ошибка, вызванная проф деформацией (мы ж разработчики, нам код писать надо). DDD это впервую очередь про процесс моделирования, а код это лишь средство. Оно дает вам набор инструментов которые применимы к коду (application level сервисы, anti-corruption layer-ы всякие) но упор надо делать на strategic domain design, который про моделирование. Который про то что бы искать зоны ответственности, субдомены, контексты, как перенести это все в модули вашего проекта. Единый язык в конце концов, семантическое ядро, какой смысл термины имеют (в том числе в разных контекстах)

Есть много технический особенностей которые делают имплементацию сильно разной. Если у вас колаборативный домен, вы можете делать там всякие CQRS/Saga/Aggregates/Eventual Consistency а можете делать локи и по старинке. Все это допустимо и исходит больше от нефункциональных требований.

3. Мы идем в DDD не разобравшись с базовыми вещами при проектировании систем - coupling/cohesion - важно поскольку позволит проще понимать все ок или не ок (вот ваш вопрос как раз про это). Information hiding - очень важно понимать что бы проще было разобраться что такое под-домены/bounded context. Можно еще добавить к этому скажем распределенные системы (всякие микросервисы) и тогда пласт необходимых знаний становтся еще больше. DDD тут лишь поможет соединить технические штуки и исследование предметной области.

4. Мы хотим в DDD но у нас нет доменных экспертов, мы сами плохо понимаем домен и процессы которые происходят у бизнеса (скажем смотрим только с позиции покупателя игнорируя бэкофисы всякие и в целом плохо понимаем value chain).