Означают ли богатые доменные модели, что большие классы доменов приемлемы?

Question

Я много читал о SOLID и Domain Driven Design, а затем о дебатах по анемичным моделям доменов и моделям с расширенным доменом.Лично я предпочитаю подход, при котором объект будет инкапсулировать свое собственное знание предметной области, однако, поскольку существует, по-видимому, некоторое расхождение во мнениях, у меня есть несколько вопросов:

1. В зависимости от типа системы основные классы предметной области могутполучить довольно большой, даже если логика методов в отдельных классах.Является ли приемлемым, что принцип единой ответственности здесь игнорируется, или есть способ инкапсулировать, скажем, Order с 50 полями и 50 методами, в красивую структуру, которая не оставляет вас с классом 1mb, или это приемлемо с учетом инкапсуляцииподход?
2. Существуют ли какие-либо руководящие указания или практические рекомендации относительно того, что по-прежнему должно входить в доменную службу или даже в доменную фабрику, при попытке сохранить расширенную модель домена и инкапсуляцию?

Answer 1

Никогда нельзя иметь объект, имеющий 50 методов, и использование «богатых» объектов на самом деле не приводит к этому.Если у вас есть это, вы можете использовать стандартные методы рефакторинга для решения проблемы.

У SRP есть много интерпретаций, но в одном из них это означает, что «вещи, которые меняются вместе, должны быть вместе».Т.е. «законно» иметь в одном классе связные вещи.Вот некоторые подробности об этом: Принцип единой ответственности .

Если вы выполняете «расширенное» моделирование, то есть объектную ориентацию, то Службы использовать не следует.Сервисы - это сценарии без сохранения состояния (т. Е. Процедуры), которые обычно обращаются к данным из других объектов, что-то с ними делают и возвращают в другие объекты.Помимо концептуальных / модельных проблем, это приводит и ко всевозможным практическим проблемам.Вот презентация с чуть более подробной информацией: Объектно-ориентированный доменно-управляемый дизайн .

Кроме того, я просмотрел репозиторий Вона Вернона в поисках как / почемуСервисы используются, и я не нашел ни одного с функциональностью, которая не имела бы лучшего места в реальном объекте.

Фабрики немного отличаются, они являются чисто технической вещью для абстрактной конструкции идолжен содержать только строительный код.

Answer 2

SRP всегда применяется. Я хотел бы спросить себя, имеет ли эта сущность смысл в целом, или было бы легче понять ее и поработать с ней, если вы сможете найти некоторую внутреннюю подструктуру и разделить ее таким образом.

Если у вас есть порядок из 50 полей, на самом деле это может быть классический случай, когда применяется ограниченный контекст , то есть, когда порядок может рассматриваться по-разному в разных подсистемах, и только части заказа необходимо каждой подсистеме.

Для «Фабрики доменов» эмпирическое правило заключается в том, что оно содержит все, что связано с созданием объекта.

Для «Службы домена» это, кажется, куча логики без сохранения состояния, которая логически не вписывается в сущности. см. .

P.S. Я не думаю, что класс 1 МБ (10 000 строк кода или более) когда-либо приемлем для любой методологии разработки программного обеспечения (если только он не является сгенерированным кодом и, следовательно, не предназначен для людей). К сожалению, иногда код достигает этого состояния случайно из-за отсутствия планирования проекта, боязни рефакторинга или преднамеренного упущения (решение отложить технический долг). Это зависит от приложения и языков программирования, но мое личное правило - начинать беспокоиться и улучшать дизайн, если класс достигает 1 тыс. Строк или даже немного раньше.