Автор ставит под вопрос применение принципов объектно-ориентированного проектирования, в частности инкапсуляции, в сложных сценариях, таких как дублирование объектов и управление версиями. Он признает важность хранения данных с поведением, но испытывает трудности в определении, какой объект должен знать, как выполнять определенные действия. Автор приводит пример модели Родитель-Потомок, где Родитель должен координировать дублирование вложенных записей. Это поднимает вопрос о том, где разместить логику координации, охватывающую несколько объектов. Предлагаются три варианта: использовать шаблон оркестратора или сервис-объекта, сделать корневой объект агрегата ответственным или делегировать дублирование вложенному объекту. Каждый вариант имеет свои плюсы и минусы, такие как сохранение логики координации вне моделей домена против накопления логики координации в корневом объекте агрегата. Автор заключает, что инкапсуляция является ценной, но контекстуальные поведения, такие как управление версиями и дублирование, не всегда принадлежат доменным объектам. Эти поведения являются временными, межобъектными и могут требовать знаний, которые объект не должен иметь. Решение лежит в переосмыслении того, какой контекст и объект наиболее подходят для инкапсуляции. Этот подход признает, что доменные сущности моделируют состояние и инварианты, а не каждый процедурный поток, и не является предательством принципов объектно-ориентированного проектирования.
dev.to
What happens when OOP meets Real World™
Create attached notes ...
