задача AR согласованность - шо это значит?

если ты данные только читаешь то срать как - на согласованность данных это не влияет (если на пути нет кэша + данные могут устареть сразу после чтения).

и если ты читаешь данные то ваще посрать агрегаты или нет - агрегат граница транзакции. нет транзакций то посрать

потому все ж ракрути дальше цепочку - интересно же

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

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

Entity -> generateReport(ReportServicePDF){ return service->output(this->privateData}

Вот так вы не раскрываете ваши внутренние данные плюс генерируете что душе угодно. Ну там само собой интерфейсы на вход и возврат.

Но в большинстве случаев это оверхед. Проще из рид модели достать нужные вам данные. Потому как подозреваю что отчёт генерится явно не по одной сущности

да, я так часто делаю
но вот такого вчера начитался https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/
говорят лучше логику фрагментировать (пожертвовать полнотой), чем чистоту модели нарушать инжектя сервисы

ага
разве что тут не отчет, а именно доки, но не суть

Я не могу вам сказать что делать. Потому что каждый подход рабочий. У каждого подхода свои плюсы и минусы

а где крутого хакера найти? кто знает?

Я отчеты генерирую в хендлерах   По сути это сервис который на вход получает рид репозитории и генератор отчета

Мне так удобнее. Так понятнее для меня код. В вашей команде вы можете принять вариант что я дал выше

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

Это всего лишь один из способов. И инжектите вы не генератор файлов, а внешний интерфейс вывода. Что тоже не лишено смысла

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

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

на чтение пофигу. Ты ничего не меняешь - стэйт остается таким же. как следствие никаких проверок инвариантов не надо.

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

попахивает вопросом, зачем тебе загружать все элементы, когда нужно сделать что то с одним? может быть, стоит из базы достать  только то, что надо?

у меня агрегаты) действие вызывается через AR, а не напрямую