смотри. Есть цикл жизни сущности. Возможно тот грид который нужен для создания поля и тот грид который будет следить за инвариантами это разные вещи. Возможно ты можешь сделать просто фабрику которая выплевывает коллекцию/итератор полигонов и на этом этапе уже применять batch processing

ну то есть "агрегаты" != "сущности". Сущности обычно больше. Агрегаты же нужны что бы гарантировать соблюдение инвариантов и обычно стараются делать их как можно меньше. То есть агрегат "Игра" которая хранит в себе всех игроков, поле и предметы - плохой агрегат потому что взаимодействие с оными происходит синхронно и нет возможности паралелить операции

Эрик Эванс не раз говорил что "зря я про сущности втирал в начале книги, не надо было"

Агрегат "Игра" может быть реализован как угодно, в том числе с многопоточностью, асинхронностью, блекджеком и рулеткой

Если игра однопользовательская то да :)

Агрегат = партиция данных гарантирующая консистегтность этих данных. Гарантии эти достигаются за счёт того что агрегат работает со стэйтом в памяти (тоесть возможны атомарные операции) и не предоставляет доступа к своему стэйту (никак)

Опять же нет конкурентых операций то можно и "агрегат игра"

Ну вот опять то из агрегата можно читать, если только не для условий, то доступа к стейту никак не предоставляет. Тяжко)

если нигде не будет записи, последущей после чтения внутреннего стейта агрегата, то почему и нет?

Проблема не в самом чтении стейта, а в том, чтобы не принимать решений, основываясь на знания стейта агрегата, вне этого агрегата

никто не обладает наиболее актуальными данными кроме самого агрегата

Да, стоило уточнить что речь про запись, но вообще лучше не юзать агрегаты на чтение

Более того они внутри не могут устареть

По определению

А это как?

Ну втупую это решается версиями

Аля оптимистичная блокировка

Есть апи и 2 личных кабинета. Для админа и для клиента.
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.

Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра

с тем же вопросом сталкивался - мне кажется отдельно надо делать

Может можно попытаться задаваться вопросом - "Что будет, если изменится 1 эндпоинт - должен ли поменяться другой?"

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