A
видел такое:
BusinessRule1::visit(model)
BusinessRule2::visit(model)
BusinessRule3::visit(model)
BusinessRule1::visit(model)
BusinessRule2::visit(model)
BusinessRule3::visit(model)
Size: a a a
2021 July 06
A
не то что это ок, но кто-то для этого придумал Visitor
PD
Но эти правила - не про одну модель, а про их связи. Так что через визитор не очень...
A
Из того же проекта
BusinessRule1::visit(new Context1(model1, model2, model3))
BusinessRule1::visit(new Context1(model1, model2, model3))
A
все, больше не шучу
A
придумать можно что угодно и даже обосновать это
AM
В моей картине мира - "рич модель" и "нормальное ООП" - это одно и тоже. Я в целом согласен с тем что ты пишешь, расхождения исключительно в терминологии.
AM
+
AM
Если workflow затянуть полностью в домен, то вполне можно всю бизнес-логику реализовать на уровне домена. У меня пока получается.
PD
Ну, просто то, что я видел под флагом rich model - мне казалось про очень тесную связь и очень сложные модификации.
Когда rm - это просто про то, что сущность сама обеспечивает свою внутреннюю целостность - то вопросов нет.
Когда rm - это просто про то, что сущность сама обеспечивает свою внутреннюю целостность - то вопросов нет.
VN
А что больше нравится хореография или окрестрация?
PD
А вот тут сложно, все равно точки конфигурации нужно куда-то выносить.
Для меня важно, что доменные объекты не должны зависеть от конфигурации.
Для меня важно, что доменные объекты не должны зависеть от конфигурации.
AM
Зачем нужно 255 полей в одном объекте? Тут явно не в ломбоке проблема.
PD
Практически только оркестрация. Хореография очень сильно мешает при развитии системы и вообще делает систему малоуправляемой.
Иногда отдельные кейсы проще сделать через хореграфию, но их очень мало.
Иногда отдельные кейсы проще сделать через хореграфию, но их очень мало.
AM
У меня бизнес-правила - это отдельный элемент доменной модели. В форме "если событие1, то выполнить команду2. "
PD
Но это же не правила, это сценарии?
PD
Правила - это про целостность связей сущностей...
У меня обычно обеспечивается транзакциями на уровне бизнес-сценариев.
У меня обычно обеспечивается транзакциями на уровне бизнес-сценариев.
AM
Опять же, вопрос терминологии. Можно попробовать обсудить термины и придти к какому-то общему виду. Потому что на смысловом уровне я не вижу сильных противоречий.
PD
Ну, это да )
p
Взаимодействия сложно на ООП описывать. А у ФП есть ленивость, чистота и развитая систем типов, особенно если есть зависимые типы.