зависит друг от друга. Нам нужно гарантировать их транзакционную согласованность. Не итоговую. Простой пример: товары с динамическими наборами свойств. При изменении свойства, которое уже используется в каких-то товарах, должна происходить какая-то бизнес-логика.
Например, нельзя сделать свойство обязательным для заполнения, если хотя бы у одного товара есть это незаполненное свойство. Пришли к тому, что такую согласованность может гарантировать доменный сервис. Вопрос заключается в следующем: как нам максимально защитить изменение этого состояния мимо сервиса-оркестратора?
Пока я вижу только 1 способ. И это изменение состояние сущности с помощью рефлексии в сервисе-оркестраторе. Т.е., в сущности не должно быть публичного метода:
public function markRequiredForValueFilling(ProductManager $actor): void
Он должен быть только приватным. Понятное дело, что при большом желании на прикладном уровне можно сделать тоже самое. Но над этим нужно будет специально заморочиться, а не просто вызвать:
$spec->markRequiredForValueFilling($actor);
Ну еще вариант сервис передать в саму сущность, который проверит что надо и даст подтверждение/отклонение
Интересный вариант🤔
Транзакционная консистентность это же по агрегаты?
Не могут они быть агрегатами. Отношение *-*
Вначале мы думал что это агрегаты, да)
https://www.typescriptlang.org/play#code/MYGwhgzhAEDCYCdoG8BQ0PQJYBMBc0EALglgHYDm0AvNAOQCMdA3OpjqQG4CmCAkjggFipSgG0AujWiTWbDGBw4AIl14AKDlh4ICq7bwCUKeZgxYAZtHVEAFlggA6LToFOQ3SnYwA+WgBZjNDMQzDsEAHsAd2gybhiAUQRIhHU6ABUIiOgAWzAyAE9oF14IOkNWUIwAX1RTMzsHZzV+QUcABwBXCFtNFsdcCrqq6BIi4JH2fsUceFTGiCGR6uhgMCJgW2tuIPqqheaDVqd2iPb1Ib3Q8Ojobkqq2rNa2tRQSBh9HRMzXGESchUWiMFimNbHf6iCiSaSyYaYGZzdTgghzXYjSzWA7gtyODxeLZ+aAAJnRkwwNxicUSyQiqQyWVy+SK4LKS0e8NCmPUAEJwYdXG1yKBOjhuBAbPYnIMyeTKbF4tAkik0gBVCDcVaIRwzL68XLcOwRHCjbIfLAUMjQMBahDlB6hV4jbGIXFdHrI7WDB3QF51CydMjAIhYCJW7rceAai4-TDAMPEW3SalwRAXH3xsiJkpIWgpvWpS5mfm6lp9I5FuMJiIePERCiehBDV6oCNR7jpoA
А, ну да. Если многие ко многим, то, чтобы гарантировать наличие связи, надо либо делать один жирный агрегат, либо делать несколько, но в некоторых юзкейсах бизнес правило на наличие связи будет выходить за границы агрегатов. Ну либо eventual consitency
Обсуждают сегодня