и пользовательских событий. Есть сервис менеджер которому надо отдать агрегат. Естественно есть пара репозиториев которые ходят куда-то за данными. Вопросик: как лучше строить агрегат из юзера и допустим 50 его последних действий с пагинацией? Я видел умные решения где этот агрегат собирают в контроллере, обычные решения где его собирают в сервисменеджере, хитрые решения где делают отдельный запрос в хранилище и оптимизированные решения где вообще нет агрегата и клиент ходит за каждой сущностью в свой энд пойнт. Как бы вы решили такую простую задачку и почему?
А где тут собственно вопрос?
хмммм.... агрегаты... несколько репозиториев..... а там точно "агрегат"?
What is aggregating?
вот кстати да, вы много говорите про агрегат, могли бы вы дать свое определение термину, это же довольно не означное слово
есть агрегаты которые описывает Эванс в своей синей книге. Он там описывает "проблема" и "агрегат как паттерн ее решающий". Вполне ознозначная штук. мол проблема - у нас есть некий набор бизнес правил и ограничений которые больше про то как данные между собой соотносятся и их неудобно выражать в виде констрейнтов в базе. решение - давайте мы из базы будем забирать кусок данных нужных для этой транзакции, вешать в базе лог и за целостности этого куска будет отвечать код внутри объекта-агрегата. То есть агрегат - это некая граница кусочка стэйта которая ВСЕГДА обязана быть консистентной. А с точки зрения стораджа это просто key-value. забрали по айдишке, оно там чет внутри пересчиталось - положили по айдишке
кусок стейта сущности
там есть нюансы: - агрегаты не должны пересекаться. То есть буквально содержимое агрегата другим транзакциям трогать нельзя. Я хз как у всех а до меня это ограничение далеко не сразу дошло когда я погружался в этот дивный мир. И если это ограничение примерять много интересного начнет в голову идти - агрегаты проектируются не по сущностям а по операциям которые ты с сущностями вытворяешь. Иначе у тебя нарушается предыдущий пункт. - сущности как объекты реального мира и вот этот весь булшит сильно уменьшают спектр возможностей по моделированию домена. Ибо слова и названия громкие и их смысл сильно зависят от контекста. Как мы подтвердили это с определением агрегатов
получаю таску на фичу и делаю пекейдж бай фича + функшинал кохижн + агрегат, часть данных сущности которые нужны в фиче и более менее норм должно быть (или нет)
Обсуждают сегодня