Анемичная доменная модель

Анемичная модель предметной области описывается как антишаблон программирования , в котором объекты предметной области практически не содержат бизнес-логики, такой как проверки, вычисления, правила и т. д. Таким образом, бизнес-логика встроена в архитектуру самой программы, что делает рефакторинг и обслуживание более сложными и трудоемкими.

Обзор

Впервые этот антипаттерн был описан ^[1] , Мартин Фаулер который считает эту практику антипаттерном . Он говорит:

Фундаментальный ужас этого антишаблона заключается в том, что он противоречит основной идее объектно-ориентированного проектирования; который заключается в объединении данных и обработки вместе. Анемичная модель предметной области — это всего лишь процедурный стиль дизайна, именно то, с чем такие фанатики, как я… боролись с первых дней нашего существования в Smalltalk . Что ещё хуже, многие люди думают, что анемичные объекты — это реальные объекты, и поэтому совершенно упускают из виду суть объектно-ориентированного проектирования.

В анемичном дизайне предметной области бизнес-логика обычно реализуется в отдельных классах, которые преобразуют состояние объектов предметной области. Фаулер называет такие внешние классы сценариями транзакций . Этот шаблон является распространенным подходом в приложениях Java , возможно, поощряемым такими технологиями, как ранние версии EJB Beans Entity , ^[1] а также в приложениях .NET , соответствующих архитектуре трехуровневых приложений служб, где такие объекты попадают в категорию «Бизнес-субъекты» (хотя бизнес-субъекты также могут содержать поведение). ^[2]

Фаулер описывает шаблон сценария транзакции следующим образом:

Большинство бизнес-приложений можно рассматривать как серию транзакций. Транзакция может рассматривать некоторую информацию как организованную определенным образом, другая вносит в нее изменения. Каждое взаимодействие между клиентской системой и серверной системой содержит определенное количество логики. В некоторых случаях это может быть так же просто, как отображение информации в базе данных. В других случаях это может включать в себя множество этапов проверок и расчетов. Сценарий транзакции организует всю эту логику главным образом в виде одной процедуры, осуществляющей вызовы непосредственно к базе данных или через тонкую оболочку базы данных. Каждая транзакция будет иметь свой собственный сценарий транзакции, хотя общие подзадачи могут быть разбиты на подпроцедуры. ^[3]

В своей книге «Шаблоны архитектуры корпоративных приложений» Фаулер отметил, что шаблон сценария транзакций может подходить для многих простых бизнес-приложений и устраняет сложный уровень объектно-ориентированного отображения базы данных.

Анемичная модель предметной области может возникнуть в системах, на которые влияет сервис-ориентированная архитектура, где поведение не меняется или имеет тенденцию не меняться, например, в архитектурах обмена сообщениями/конвейерах или API-интерфейсах SOAP / REST . Такие архитектуры, как COM+ и Remoting, допускают определенное поведение, но в Интернете все чаще отдаются предпочтение отключенным архитектурам и архитектурам без сохранения состояния.

Критика

Существует некоторая критика относительно того, следует ли считать этот шаблон проектирования программного обеспечения антишаблоном, поскольку многие видят в нем и преимущества, например:

Четкое разделение логики и данных. ^[4]
Хорошо работает для простых приложений.
Результатом является логика без сохранения состояния, которая облегчает масштабирование.
Устраняет необходимость в сложном уровне сопоставления объектно-ориентированной базы данных.
Больше совместимости с фреймворками сопоставления и внедрения, ожидающими глупых свойств, а не конкретного конструктора или порядка заполнения свойств. ^[4]

Распространенной критикой является идея о том, что анемичная доменная модель облегчает следование принципам SOLID :

«Буква «S» относится к принципу единой ответственности , который предполагает, что класс должен делать что-то одно, и делать это хорошо (...)». ^[5]

Но, по мнению Роберта К. Мартина , это неправильное понимание этого принципа:

«Из всех принципов SOLID принцип единой ответственности (SRP), возможно, наименее понятен. Вероятно, это потому, что у него особенно неподходящее имя. Программистам слишком легко услышать это имя, а затем предположить, что оно означает, что каждый модуль должна делать только одну вещь. Не заблуждайтесь, существует такой принцип. Функция должна делать только одну вещь. Мы используем этот принцип, когда реорганизуем большие функции в более мелкие функции, мы используем его на самых низких уровнях; Но это не один из принципов SOLID — это не SRP (...) окончательная версия SRP такова: модуль должен быть ответственным перед одним и только одним субъектом. ^[6]"

Обязательства

Определенные обязательства, которые должен учитывать программист, вводятся с помощью анемичной модели предметной области:

Логика не может быть реализована по-настоящему объектно-ориентированным способом.
Нарушение принципов инкапсуляции и сокрытия информации .
Требуется отдельный бизнес-уровень для хранения логики, которая в противном случае находится в модели предметной области . Это также означает, что объекты модели предметной области не могут гарантировать свою корректность в любой момент, поскольку их логика проверки и мутации размещена где-то снаружи (скорее всего, в нескольких местах).
Требуется уровень обслуживания при совместном использовании логики предметной области между разными потребителями объектной модели.
Делает модель менее выразительной. .

Пример

Анемичная модель предметной области будет иметь один код записи, подобный следующему (написанный на C# ), который сам по себе не реализует никаких бизнес-задач, в данном случае, что высота или ширина не могут быть нулевыми или отрицательными, или что-то еще есть требование к площади прямоугольника. Это означает, что эти функции реализованы где-то еще, уже не на «бизнес-стороне» программы, а где-то еще, скрыто внутри ее архитектуры.

class Rectangle
{
    public int Height { get; set; }
    public int Width { get; set; }
}

Неанемичное переписывание вышеуказанного класса может выглядеть следующим образом. Бизнес-задачи теперь решаются в объекте предметной области, а архитектура может быть более независимой от предметной области. Это позволяет программе предполагать, что определенные атрибуты объектов верны, не выполняя проверки достоверности где-либо еще в архитектуре.

class Rectangle
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Rectangle(int height, int width)
    {
        SetHeight(height);
        SetWidth(width);
    }

    public void SetHeight(int height)
    {
        if (height <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(height));
        }

        Height = height;
    }

    public void SetWidth(int width)
    {
        if (width <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(width));
        }

        Width = width;
    }

    public int CalculateArea()
    {
        return Height * Width;
    }
}

См. также

Обычный старый объект Java
Доменно-ориентированный дизайн
Информационный эксперт GRASP , анемичная модель предметной области является типичным результатом отказа от применения принципа информационного эксперта, т. е. вы можете избежать анемичной модели предметной области, пытаясь распределить обязанности по тем же классам, которые содержат данные.

Ссылки

^ Jump up to: ^а ^б "Bliki: AnemicDomainModel" .
^ «Архитектура приложений для .NET: проектирование приложений и сервисов» . Архивировано из оригинала 10 января 2013 г. Проверено 13 февраля 2013 г.
^ «P EAA: сценарий транзакции» .
^ Jump up to: ^а ^б «Модель анемичного домена — это не антипаттерн, это НАДЕЖНАЯ конструкция – SAPM: Блог курса» . 4 февраля 2014 г.
^ «Модель анемичного домена — это не антипаттерн, это НАДЕЖНАЯ конструкция – SAPM: Блог курса» . 4 февраля 2014 года . Проверено 14 сентября 2022 г.
^ Мартин, Роберт С. (2018). Чистая архитектура: руководство для мастера по структуре и дизайну программного обеспечения . Бостон. ISBN 978-0-13-449432-6 . OCLC 1003645626 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

Внешние ссылки

[fowler-1] Jump up to: ^а ^б "Bliki: AnemicDomainModel" .

[microsoft-2] «Архитектура приложений для .NET: проектирование приложений и сервисов» . Архивировано из оригинала 10 января 2013 г. Проверено 13 февраля 2013 г.

[3] «P EAA: сценарий транзакции» .

[SAPM-4] Jump up to: ^а ^б «Модель анемичного домена — это не антипаттерн, это НАДЕЖНАЯ конструкция – SAPM: Блог курса» . 4 февраля 2014 г.

[5] «Модель анемичного домена — это не антипаттерн, это НАДЕЖНАЯ конструкция – SAPM: Блог курса» . 4 февраля 2014 года . Проверено 14 сентября 2022 г.

[6] Мартин, Роберт С. (2018). Чистая архитектура: руководство для мастера по структуре и дизайну программного обеспечения . Бостон. ISBN 978-0-13-449432-6 . OCLC 1003645626 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

[1]

[2]

[3]

[4]

[5]

[6]