В недавнем выпуске подкаста DotNet&More мы обсуждали с Максимом Аршиновым его предстоящий доклад на Московский .Next "Блеск и нищета предметной модели". С позицией Максима можно будет легко познакомиться непосредственно на конференции. И, в качестве дополнения, я бы хотел рассмотреть видение великого спора Анемичная VS "Богатая" ("Насыщенная") доменные модели через призму некогда популярных GRASP шаблонов
Дискуссии идут достаточно давно, например:
- Anemic Domain Model [Перевод]
- [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
Судя по 190 комментариями к последней статье, данная тема не теряет актуальности.
Прежде чем начать разбор, хотелось бы прояснить предмет спора. Основное отличие анемичной модели от богатой в том, что она не содержит бизнес логику в теле класса. Частным примером анемичной модели может быть всем известный паттерн DTO.
"Богатая" модель, в свою очередь, может содержать логику, описывающую бизнес правила, функции и т.д. Обратите внимание, что мы рассматриваем именно методы, отражающие бизнес логику. ToString, GetHashCode и прочие "технические" части классов не входят в предмет обсуждения, потому и игнорируются.
GRASP
Как и отмечалось в начале статьи, рассматривать данный вопрос мы будем в контексте GRASP паттернов. Данный набор шаблонов был представлен в книге Крэга Лармана «Применение UML и шаблонов проектирования» и сильно повлиял на современное программирование, например, правила Low Coupling/High Cohesion были объявлены именно в GRASP.
Для людей, знакомых с GoF паттернами данный набор шаблонов может показаться слишком размытым. Все дело в том, что GRASP паттерны сфокусированы не на решении прикладных задач, а на распределении ответственности за те или иные действия и операции между объектами:
- Creator отвечает за создание объектов
- Controller отвечает за операции от пользователей
- Indirection отвечает за организацию слабого зацепления между объектами
И так далее.
В контексте данной статьи хотелось бы сфокусироваться на следующих паттернах:
- Information Expert (Информационный эксперт)
- Pure Fabrication (Чистая выдумка)
Information Expert (Информационный эксперт)
Проблема: Каков базовый принцип распределения обязанностей между объектами?
Решение: Назначить эту обязанность тому классу, который обладает достаточной информацией для ее выполнения.
Другими словами:
Ответственность должна быть назначена тому, кто владеет максимумом необходимой информации для исполнения — информационному эксперту.
В контексте C#: метод стоит объявлять в том классе, поля и свойства которого используются в этом методе.
Например, если для расчета суммы долга вся необходимая информация есть у сущности должника (сумма, время выдачи кредита), то именно в этой сущности и стоит объявить соответствующий метод.
Конечно, данное упрощение несколько чрезмерно, но основной смысл должен быть понятен.
Pure Fabrication (Чистая выдумка)
Проблема: Какой класс должен обеспечить реализацию High Cohesion и Low Coupling, если шаблон Information Expert не обеспечивает подходящего решения.
Решение: Присвоить группу обязанностей с высокой степенью зацепления искусственному классу, не представляющему конкретного понятия предметной области.
Другими словами:
Если однозначно выбрать подходящую сущность предметной модели, которой можно было бы назначить ответственность, не удается, необходимо создать синтетический класс, не существующий в предметной области.
В контексте C#: если реализация метода предусматривает равномерное использование нескольких сущностей или внешних зависимостей, то данный метод стоит объявить в отдельном классе. И эти классы называют сервисами.
Например, если для расчета суммы долга необходимо знать не только атрибуты должника, но и параметры банка (процентная ставка, допустимый период просрочки), то стоит создать отдельный сервис, содержащий соответствующий метод.
И что это все значит?
В контексте вышесказанного, можно выделить достаточно простой алгоритм, помогающий принять решение, располагать метод в модели или в сервисе:
- Если метод использует только свойства модели, его стоит объявить в модели
- Если метод использует, по большей части, свойства одной модели и лишь частично другой, его можно объявить в модели
- Если метод равномерно использует свойства нескольких моделей, то стоит вынести его в отдельный или существующий сервис
- Если метод использует внешнюю зависимость, например Репозиторий, его стоит вынести в отдельный или существующий сервис
Резюме
GRASP паттерны нельзя рассматривать как истину в последней инстанции. Но в они могут помочь легко понять, какому объекту назначить то или иное поведение. Соответственно, спор анемичная или "богатая" модель может не иметь смысла, так как решение принимается в каждом конкретном случае, в зависимости от модели предметной области и поведения, связанного с ней. В процессе дизайна системы будут появляться как сущности с поведением, так и без него. И это вполне корректно.
