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

62
9

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

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

спросил(а) 2019-03-26T00:13:00+03:00 1 год, 11 месяцев назад
1
Решение
75

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

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

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

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

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

ответил(а) 2019-03-26T01:05:00+03:00 1 год, 11 месяцев назад
43

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

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

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


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

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

ответил(а) 2019-03-26T11:39:00+03:00 1 год, 11 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема