Анемичная модель данных, дао, ... авторитетная ссылка?

Question

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

Являются ли анемичные модели данных ( (c) Martin Fowler?) Изначально плохими? Должен ли пирог выпекать сам? Должен ли счет-фактура знать, как (и когда это должно позволять) добавлять строки в себя, или другой слой должен это делать? rabbit.addToHole(дыра) или hole.addRabbit(кролик)? Было ли доказано, что ADM более подвержен ошибкам, проще в обслуживании или чем-то еще?

Вы можете найти много претензий в Интернете, но я бы очень хотел получить авторитетные цитаты, ссылки или факты, если это возможно, с обеих сторон.

Answer 1

Посмотрите этот ответ на stackru для просветления.

И это мое мнение

ADM (модель анемичного домена) не может быть представлена ​​диаграммой классов UML

Модель анемичной области плоха, только с точки зрения полного опа. Это считается плохим дизайном, в основном потому, что вы не можете создавать UML-классы и отношения со встроенным поведением внутри него. Например, в вашем классе Invoice с расширенной моделью домена (RDM):

• Название класса: заказ
• Реализовано: ICommittable, IDraftable, ...
• Атрибуты: Нет, UserId, TotalAmount, ...
• Поведение: Commit(), SaveDraft(), ...

Класс самодокументирован и объясняет, что он может делать, а что нет.

Если это анемичная модель предметной области, она не имеет такого поведения, и нам нужно найти, какой класс отвечает за фиксацию и сохранение черновика. А поскольку диаграмма классов UML показывает только отношение между каждым классом (один ко многим / много ко многим / агрегатный / составной), связь с классом обслуживания не может быть задокументирована, и Мартин Фаулер имеет право на свою точку зрения.

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

Это основано на диаграмме классов UML в книге OOAD Lars Mathiassen, Я не знаю, может ли более новая диаграмма классов UML представлять класс обслуживания.

SRP

С точки зрения ADM и компримирования по наследованию RDM (модель расширенного домена) нарушает SRP. Это может быть правдой, но вы можете обратиться к этому вопросу для обсуждения.

Вкратце, с точки зрения ADM, SRP равняется одному классу, выполняющему одно и только одно. Any change into the class has one and only one reason.

С точки зрения RDM, SRP равняется всей ответственности, связанной и только с самим интерфейсом. Как только операция задействует другой класс, операцию необходимо поместить в другой интерфейс. Сама реализация может варьироваться, как таковая, если класс может реализовывать 2 или более интерфейсов. Это просто сказано как if an operation in interface need to be changed, it is for and only for one reason,

ADM, как правило, злоупотребляют статическими методами, и могут применяться грязные хаки

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

У ADM может быть много грязных хаков, потому что операции не ограничены определением объекта (эй, я могу создать для этого другой класс!). В руках плохого дизайнера это может стать катастрофическим. В RDM это сложнее, пожалуйста, прочитайте следующий пункт для информации.

Реализация RDM обычно не может быть повторно использована и не может быть поддельной. RDM требуют заранее знать поведение системы

Обычно реализация RDM не может быть повторно использована и осмеяна. В режиме TDD это снизило тестируемость (пожалуйста, исправьте меня, если есть RDM, который можно смоделировать и использовать повторно). Представьте себе ситуацию с этим деревом наследования:

    A
   / \
  B   C

Если B нужна логика, реализованная в C, это невозможно сделать. Используя композицию по наследству, это может быть достигнуто. В RDM это можно сделать с помощью такой конструкции:

    A
    |
    D
   / \
  B   C

В котором ввести больше наследства. Тем не менее, для того, чтобы на раннем этапе добиться аккуратного проектирования, вам необходимо знать, как работает система из первых уст. Тем не менее, RDM требует, чтобы вы знали поведение системы перед выполнением какого-либо проектирования, иначе вы не будете знать ни один из интерфейсов, названных ISubmitable, IUpdateable, ICrushable, IRenderable, ISolved и т. Д., Подходящих для вашей системы.

Заключение

Это все мое мнение об этом виде священной войны. У обоих есть плюсы и минусы. Я обычно обращаюсь к ADM, потому что кажется, что большая гибкость даже меньше надежности. Независимо от ADM или RDM, если вы плохо спроектируете свою систему, обслуживание будет трудным. Любой тип бензопилы будет сиять только когда его держит умелый плотник.

Answer 2

Я думаю, что принятый ответ на этот вопрос - лучший ответ и на ваш вопрос.

Вещи, которые я думаю, необходимо запомнить:

• ADM подходит для приложений CRUD, и, поскольку большинство приложений запускаются таким образом, все в порядке как начальная архитектура; вы можете развиваться оттуда посредством рефакторинга, если это необходимо, но нет смысла чрезмерно проектировать приложение с самого начала
• как только сложность начинает расти - как только бизнес-правила начинают накапливаться - менее удобно сохранять модель анемичной - отделение правил от объектов, на которые они действуют, затрудняет запоминание всех правил, которые применяются, когда вы смотрите на объект
• если правила находятся в объектах домена, они также способствуют написанию тестов, если они в другом месте (например, в службах без сохранения состояния), вы не знаете, что может делать объект домена и каковы все ограничения, которые к нему применяются, написать надлежащие тесты для этого (подумайте об ортогональных правилах, смоделированных в разных сервисах)
• необходимо проводить различие между действительно простыми приложениями и моделями анемичных доменов: в действительно простом приложении не так много бизнес-логики, в модели анемичных доменов логика существует, но она хранится отдельно от модели доменов