Какая то граница где данные меняются атомарно. И эта граница не пересекается с другими

В результате у нас появляется eventual consistency

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

не обязательно

Ну например если все один агрегат.
Или когда мы меняем и лочим в одной транзакции  вместе X1 и X2 , а потом X2 и X3

это агрегаты?

Это условные данные

Которые мы меняем

У меня не хватает знаний, не пойму в чем вопрос :)

Как можно менять "условные данные" без агрегатов? Или это вообще отказаться от сущностей и просто чтото менять в бд произвольно?

Ну вот пример
есть данные
A B C D
есть инварианты
A > B
C < D
(B + C) > 100
есть юзкейсы
хотим поменять A - лочим A,B
хотим поменять B - лочим A,B,C
и т.д.

какие тут агрегаты?

ну тут получается a, b, c, d - сущности/агрегаты и они должны иметь итоговую согласованность, так выходит?

Я не знаю:) Я просто пытаюсь рассуждать логически.
Ты спросил как можно без агрегатов, вот как пример. Или если же агрегаты существуют всегда, то мне вот хотелось бы понять где границы в моем примере

а зачем дробить стэйт?

ну то есть, мне кажется вопроса "как без агрегатов" небыло, можно просто не называть агрегаты агрегатами)

но смысл именно в декомпозиции модели, разделении ее на составные части и вот это все.

По идее, DDD учит, что если все три инварианта выше очень важны и должны быть атомарны, то это один агрегат. Но в тоже время в примере выше можно менять 2 значения одновременно.

Хз, интересно узнать 🙂
Я думаю для того, чтобы функции не имели лишних зависимостей. Те чтобы мы могли работать только с тем, что нам нужно

Я видел, что ты писал - можно все разбить на (one value + ID)

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

Тут сложность именно в том что бы определить какие из инвариантов стэйта являются true invariants и на самом деле требуют этой самой immidiate consisntency. ДДД тут учит именно что ты не можешь знать ответ на этот вопрос без колаборации с бизнесом и без построения модели вместе.

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

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

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