SP
$approvedReview = $review->approve();
Size: a a a
2021 April 25
ПГ
Так нужно статус товара установить после апрува отзыва. Точнее проверить что все отзывы тоже апрувнуты
SP
просто нет такого поля как "статус". У тебя статус будет просто
case
when exists select 1 FROM approved_reviews WHERE id=? then 'approved'
when exists select 1 FROM pending_reviews WHERE id=? then 'pending'
end
SP
это штука для UI а не какая-то характеристика продукта
SP
ты можешь ее даже вычислять на каждый запрос если оч хочется, можно кэшить во вью модельке
ПГ
Почему, я в начале писал, что от этого зависят бизнес процессы.
ПГ
Т.е. это не просто для UI
SP
я выше привел - у тебя просто для какой-то операции не будет агрегата соответственно все инварианты процессов будут соблюдены без необходимости вводить какое-то поле
SP
ну то есть именно на инварианты стэйта системы это не влияет - как следствие это влияет на UX/UI. То есть на то что юзеры делают дальше. А это значит что поле "статус" можно вычислять по наличию/отсутствию каких-то агрегатов и т.д.
SP
"статус" это оч опасная концепция которая часто создает жирные god objects. У меня вот есть кейс где у сущности за 5 лет с простого "pending in progress done" граф перехода статусов разросся до 12-ти возможных статусов, пиздец сложной логики и все это по сути нужно только что б на UI нужные кнопки показывать
ПГ
Хорошее решение было бы 12 агрегатов?
SP
в моем случае это было бы агрегатов 5
SP
это бы закрыло разные комбинации
ПГ
Как я понял в примере, теже отзывы - это 2 разные сущности с разными таблицами
SP
и да - в этом проблема с проектирониваем агрегатов через сущности а не через процессы
SP
вот у тебя есть некий процесс. там есть какие-то activities. Вот обычно инварианты - они где-то там, переходы между активитис, какие-то изменения стэйта. И вот туда надо смотреть в их поиске
SP
сущности тут вторичны и будут лишь мешать.
SP
p.s. опять же если процесс у тебя простой или там в процессе учавствует всегда один человек (какой-нибудь личный профиль) когда вероятность конфликта операций маленькая - тогда пофигу и лучше делать проще
AV
Если можно ещё последний вопрос напоследок. Должен ли всё-таки товар знать об этих связях? Либо при создании агрегата их доставать из репозитория.
И как в случае создания агрегата через билдер гарантировать отсутсвие инвариантов у самого агрегата?
И как в случае создания агрегата через билдер гарантировать отсутсвие инвариантов у самого агрегата?
ПГ
Интересный подход, но совсем другой в плане архитектуры, надо осмыслить :)
А не добавляет ли это проблем при переходе одного агрегата в другой? Ведь ранее нужно было поддерживаться один update например. Ну и транзакция - это работа с одним агрегатом и его сущностями.
Тут же выходит что для поддержания целостности нужно 1 агрегат создать, другой удалить и при этом в одну транзакцию все это запихать. Или нет?
А не добавляет ли это проблем при переходе одного агрегата в другой? Ведь ранее нужно было поддерживаться один update например. Ну и транзакция - это работа с одним агрегатом и его сущностями.
Тут же выходит что для поддержания целостности нужно 1 агрегат создать, другой удалить и при этом в одну транзакцию все это запихать. Или нет?