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

“чаще всего это от того что "все правила одинаково важны" что не является правдой”
Но ведь может быть такое требование, как вот например в моем примере выше. Мы же можем выбирать между преимуществами в конкурентности или атомарности

не люблю на абстрактных конях обсуждать такого рода вещи, ибо всегда можно придти к примеру который ломает какую-то концепцию. Я повторюсь - из своего опыта такие ситуации как ты описал чаще всего вызваны каким-то неправильным концептом для конкретной ситуации которое создает больше зависимостей. Яркий пример - статусы. У меня под рукой есть пример сущности где граф переходов статусов настолко сложный что под него отдельная вики страничка сделана с объяснением почему че и куда.

ну то есть, "всегда есть другой способ", и не надо думать что я предлагаю "всегда так дробить". Я как раз предлагаю задавать вопросы "почему вещи надо объединять". Если ты столкнулся с такой ситуацией что "по другому не выйдет гарантировать инварианты" - ну ок, ты осознанно это делаешь.

Чаще же я вижу "о у проекта есть херня, и есть такая херня... и есть типы проектов... и у них есть свои херни... надо наверное наследование..." Ну то есть нет ни анализа юзкейсов, ни чем типы отличаются (возможно отличаются они вовсе не в плане "проектов" а скажем какие-то разные стратегии для тасок внутри проекта...). Ни анализа юзкейсов, ни анализа инвариантов... зато в резюме будет про ДДД потому что слои есть

Понял,
Спасибо большое за большой ответ:)

Возможно еще один тупой вопрос😅
А что обычно стабильнее - функции или композиция данных? Я вот по опыту не могу понять. Мб по-разному?

Те если мы собираем данные под юзкейсы, то если юзкейсы меняются, нам надо пересобирать данные - боль.
С другой стороны по какому еще критерию собирать данные, кроме как под юзкейсы, верно?

ну в том и смысл - если у тебя функционал и стэйт под этот функционал разбиты достаточно хорошо - то они по отдельности достаточно стабильны. А вся гибкость достигается композицией этого функционала. emergence такой.

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

Бизнес вообще "как правило" проблемы решает добавлением новых юзкейсов а не изменением старых (что часто проблема но не суть).

всем привет, вопрос по DDD. есть агрегат Customer у которого есть список покупок Order.
При выгрузке из БД неоптимально хранить в памяти весь список покупок и даже их id  . как в этом случае решается? логика переносится в CustomerService на уровне домена?

А это точно агрегат?

А почему Customer агрегат, а order - нет?

Вряд ли Order должен быть сущностью Customer'а. Скорее в Customer'e должен быть фабричный метод createOrder  - который и создаст вам  новый агрегат Order. С ним собственно и работайте.
Соотстветственно они будут связаны только через свойство Order'a - customer_id. А дальше можете крутить, как хотите

Прямо выше почти про это обсуждали

То есть, агрегат Order будет иметь объект Customer и список OrderInfo? А фильтр по свойствам Odred в Customer писать? Чтобы взять только те, что куплены за определенную дату

Нет таких агрегатов

Там на примере shopping cart рассматривают но вопросы order и customer тоже затрагиваются.

Агрегат != то, что нужно вашей юишке. Агрегат прежде всего контроль инвариантов, а не как вытаскивать это из бд для красивого показа

Ты сейчас говоришь про ui штуки (поиск). Про агрегаты имеет смысл говорить только в контексте изменения стэйта. Если стэйт не меняется то это все просто условный sql и dto-ки