AnemicDomainModel - нужно более простое объяснение - PullRequest
Новая
       1

AnemicDomainModel - нужно более простое объяснение

1 голос
/ 26 января 2012

Сегодня я прочитал эту статью и пытаюсь кое-что прояснить. Означает ли эта статья, что объекты модели должны содержать бизнес-логику? Например, допустим, что есть объект Student, который мы извлекаем из базы данных через Hibernate. Говорит ли эта статья, что объект Student должен также содержать бизнес-логику, а не иметь только геттеры и сеттеры?

Ответы [ 2 ]

6 голосов
/ 26 января 2012

Не обращайте внимания на дату, которая, как утверждает Мартин Фаулер, сегодня так же актуальна, как и восемь лет назад.Фаулер не утверждает, что вы должны смешивать постоянство с объектами домена, а наоборот:

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

Вы должны прочитать статью еще раз, потому что статья очень хорошо описывает этот анти-шаблон, но я постараюсь обобщить его для вас в контексте того, что вы спрашиваете:

Если вы хотите создать модель домена, да, ваши доменные объекты должны содержать как бизнес-логику, так и состояние, и изменения состояния ваших доменных сущностей должны быть сделаны с помощью методов, которые передают значение для бизнеса.Модель анемичной области является анти-паттерном, потому что вы несете расходы на дополнительный уровень классов, но не получаете выгоды.Зачем беспокоиться о доменном слое, который вы должны сопоставить с базой данных, если он передает точно такое же намерение, как и при использовании подхода с использованием стиля активных записей (набор данных и т. Д.)?Таким образом, в статье не говорится, что у вас должен быть «ученик-объект», но говорится, что если вы это сделаете, вам следует окончательно добавить состояние к этому классу.

Точка в статье о том, что у вас нет набораобъектов, которые представляют вашу модель, если вы также не моделируете свой домен, может быть немного запутанным из-за технологий, доступных сегодня.Существуют отличные инструменты, которые могут легко перемещать данные между набором POCO и базой данных (Nhibernate, EF, Simple Data, Massive, Dapper и т. Д.), Поэтому в этом ретроспективе я бы сказал, что вы, вероятно, в конечном итоге получите набор«сущности» в большинстве решений сегодня, реальная разница в том, является ли это просто моделью базы данных или моделью реального домена.

В заключение я приведу пример взаимодействия между точкой входа в домен (обработчик команд) и модель предметной области.Показанный ниже метод находится в обработчике команд, который использует запрос на изменение чего-либо в домене.Обратите внимание, что код layer-ontop-of-your-domain-просто получает объект домена и вызывает один метод в домене?Это важный момент, потому что рабочий процесс, который мы моделируем, полностью инкапсулирован в домене, а не в коде слоя поверх вашего домена или где-либо еще: 

    public void Handle(AddEmailAddressForAlerts command)
    {
        var agent = _repository.GetAgent(command.AgentKey.AgentId);
        agent.AddEmailAddressForAlerts(new EmailAddress(command.EmailAddress));
    }
1 голос
/ 26 января 2012

Обратите внимание на дату - цитате более восьми лет.

Мартин Фаулер, очевидно, очень умный парень, и мне нравится точка зрения статьи, но примите это с недоверием. Инкапсуляция состояния и поведения вместе - это хорошая вещь в целом, но она должна быть сбалансирована с учетом многоуровневых соображений. Постоянство - это не то же самое, что бизнес-логика. У меня все еще был бы отдельный уровень постоянства; Я бы не стал настаивать на модельном объекте.

Догма должна быть оспорена во всех ее формах. Будьте в курсе идей других людей, но думайте сами.

...