Вчера вышло видео от Derek Comartin на канале CodeOpinion - "You don’t need an Aggregate in DDD. Model Rules, Not Relationships". Несмотря на кликбейтность заголовка видео достойно просмотра.
Кратко о проблематике:
Как известно, агрегаты в DDD должны сохранять свои инварианты (непротиворечивость и консистентность данных). Это важнейшая задача, то ради чего в целом то агрегаты и нужны.
Но что делать если агрегат получается очень большим?
Допустим есть агрегат Chat, с правилом: в чате может состоять не более 100к пользователей.
Чтобы агрегат мог сохранить инварианты (к примеру не позволить вступить в чат больше 100к пользователей), нужно чтобы все нужные ему данные были подгружены в память. Тогда агрегат сможет делать необходимые ему валидации безопасно.
Согласитесь, никто в своем уме не захочет так делать, это слишком медленно и дорого.
У данной проблемы даже есть своё имя "DDD trilemma", о котором есть отличная статья от Владимира Хорикова - "Domain model purity vs. domain model completeness (DDD Trilemma)"
К счастью автор видео не оставляет нас без решения и предлагает в таких случаях отказаться от Domain Completeness или даже в целом от привычных агрегатов и "деградировать" до transaction script или переложить эту логику в доменные сервисы. Самое главное чтобы был подходящий под ваши требования способ обеспечения соблюдения необходимых бизнес правил.
К слову, в учебном проекте BookLibrary я тоже столкнулся с этой трилеммой, когда захотел реализовать правило - "Не более 3 книг в одни руки".
Здесь я решил пожертвовать Domain model completeness (т.к. логика немного размазана между application и domain) в пользу Domain model purity и performance.
В UseCase собираю информацию о количестве уже взятых книг и при попытке взять очередную книгу, вызывается проверка, на кол-во уже взятых книг.
Этот пример не идеален, так как нет никаких защит от параллельных запросов, это нужно учитывать.
Кратко о проблематике:
Как известно, агрегаты в DDD должны сохранять свои инварианты (непротиворечивость и консистентность данных). Это важнейшая задача, то ради чего в целом то агрегаты и нужны.
Но что делать если агрегат получается очень большим?
Допустим есть агрегат Chat, с правилом: в чате может состоять не более 100к пользователей.
Чтобы агрегат мог сохранить инварианты (к примеру не позволить вступить в чат больше 100к пользователей), нужно чтобы все нужные ему данные были подгружены в память. Тогда агрегат сможет делать необходимые ему валидации безопасно.
Согласитесь, никто в своем уме не захочет так делать, это слишком медленно и дорого.
У данной проблемы даже есть своё имя "DDD trilemma", о котором есть отличная статья от Владимира Хорикова - "Domain model purity vs. domain model completeness (DDD Trilemma)"
К счастью автор видео не оставляет нас без решения и предлагает в таких случаях отказаться от Domain Completeness или даже в целом от привычных агрегатов и "деградировать" до transaction script или переложить эту логику в доменные сервисы. Самое главное чтобы был подходящий под ваши требования способ обеспечения соблюдения необходимых бизнес правил.
К слову, в учебном проекте BookLibrary я тоже столкнулся с этой трилеммой, когда захотел реализовать правило - "Не более 3 книг в одни руки".
Здесь я решил пожертвовать Domain model completeness (т.к. логика немного размазана между application и domain) в пользу Domain model purity и performance.
В UseCase собираю информацию о количестве уже взятых книг и при попытке взять очередную книгу, вызывается проверка, на кол-во уже взятых книг.
Этот пример не идеален, так как нет никаких защит от параллельных запросов, это нужно учитывать.