не обязательно. можно же адаптер рядом хранить

я про это

чистый аггрегат + адаптер для аггрегат менеджера, который уже фреймворочный

ок, давай точнее:

типа легко разделить персистенс слой от самого аггрегата. 

они никак не пересекаются в случае трейта/базового класса

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

каким? как ты будешь обеспечивать правило?

или например инжектить некий Context
куда можно паблишить ивенты

чем это лучше базового класса/трейта со свойством?

пример с локами - позор сраный. Как с точки зрения локов, так и с точки зрения банальной логики

> они никак не пересекаются в случае трейта/базового класса

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

> каким? как ты будешь обеспечивать правило?

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

> чем это лучше базового класса/трейта со свойством?

ничем, кроме того что не будет базового класса/трейта.

а зачем этот трейт с локом

я пропустил

команды в сф локать

хмм

вот в этом и нюанс, что профит минимален, а затраты максимальны.

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

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

ну для этого и нужно писать адаптер к фреймоврку

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

либо еще что-то

что в итоге может приводить к жутким зависимостям

и какие-нибудь адепты чистоты грустят

но всем похуй, если оно и так работает

ну вон ща Валентин пишет дженериками как на котлине

локи