Это же треш

попробуй выделить некий аггрегат/сущность которая подвергается изменению как со стороны юзера так и со стороны админа
и затем попробуй ее разделить на 1 write и 2 read модели.

Write модель должна принимать на вход ряд команд которые ее меняют как со стороны админа так и юзера.

А Read модели должны содержать все необходимые поля для юзера/админа чтобы ему хватило информации на свои нужды.

как только опишешь именно через команды/евенты и итоговые read модели в виде структур.
то сразу будет понятно как его реализовать и возникнет 0 вопросов по самой модели.

но конечно не все так идеально

потому и жалеет) мол что люди основную идею за всеми этими техническими примерами не понимают)

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

потому что писать надо формалистично а не на пальцах

тут вопрос что есть сущность.

Ты не забывай - книга была написана во времена мэйнфреймов. Там даже примеры весьма специфичные (например че там он рассказывал - система для моделирования электрических цепей? однопользовательское приложение вообще)

Смысл то книги был в том что "вот сел разработчик и доменный эксперт и они сидят и разговаривают. И разработчик выражает то что говорит доменный эксперт в коде (единый язык). И разработчик может доменному эксперту вопросы задавать по коду и есть вероятность что они друг друга поймут без необходимости разработчику прям становиться экспертом в предметной области.

С тех пор появились всякие клауд компьютинг и сегодня вот serverless. Возможность динамически менять количество вычислительных ресурсов подстегивает к распределенным вычислениям и там чуть-чуть более важна декомпозиция стэйта системы и eventual consistency. А это уже другие подходы. Идея остается той же - перенос логики в код максимально близко к домену что бы иметь возможность общаться с бизнесом в его терминологии. Но решений больше.

на основе идей книги (или как минимум схожие идеи) есть и другие подходы которые примерно о том же. Появились CQRS (2008-ой год), появились всякие event storming (2014-ый вроде), появились всякие specification by example (которые про взаимодействие разработчиков и бизнеса, как способ моделирования через приемочные тесты)... Да и agile манифест и прочие XP/cristal clear которые появились в конце 90х оперируют схожими идеями.

монада кедавра

Можно ещё глупый вопрос? Есть агрегат, у которого есть список сущностей, размер которых условно большой (миллионы). Как это запихнуть в архитектуру для DDD?

Логика подсказывает, что агрегат должен быть целым. Но не каждый раз (вернее, почти никогда) нужен этот список сущностей и не каждый раз весь целиком. И при этом делать всякие list-like итераторы, которые в lazy режиме будут делать запросы в БД — выглядит как бред и Active Record.

Вопрос в том, куда девать пагинацию? Вот есть к примеру агрегат "кампания" (сбор средств, петиция, что угодно), у неё есть те, кто подписался (или внёс деньги) — сущность "подписчик". Их миллион. Целиком миллион нужен в каких-то редких случаях вроде cron-скриптов. Для поиска кампаний не нужен вообще. А для страницы кампании — пагинация. Причём, это всё — UI и не должен никак влиять на доменную модель. Но загружать каждый раз миллион из БД в память невозможно.

и тут вопрос - а зачем агрегату этот список. Подозреваю - для UI :)

то есть эти данные никак не влияют на инварианы агрегата (ибо иначе у тебя оч большой и жирный агрегат или повышается вероятность пересечения агрегатов)

Хмм. Вообще да, ты прав:) Не могу сходу придумать кейс, зачем оно может быть нужно не для UI. Но если такой кейс существует, как быть?

разбираться. Агрегаты должны быть маленькими. Как минимум потому что так понижается вероятность пересечения данных отдельных агрегатов (помимо старых добрых SOLID) и максимум - работа с агрегатом идет последовательно так как агрегат должен гарантировать целостность в любой момент времени. А вот между агрегатами у тебя появляется eventual consistency.

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

вот на эту тему можно полистать

Понял, спасибо. Пойду разбираться

Почему это один агрегат? Логически ведь это два разных агрегата со связью

Что значит "агрегат со связью"

Имею в виду, что компания и подписчики компании - это наверняка отдельные агрегаты, которые существуют отдельно, но у подписчика есть условно идентификатор компании к которой он привязан.

То есть подписчик не является часть компании и наоборот.