Является ли доменная анемия подходящей в сервис-ориентированной архитектуре?

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Возвращаясь к предыдущим проектам, я помню тот, который использовал анемичные объекты домена, у него было много проблем, в том числе ужасная homegrown xml база данных, но поскольку он занимался сервисным подходом, было легко взять на себя проблемы по одному за раз и добиваются реального прогресса. В текущем проекте они пытались быть умными и привязывать объекты домена к базе данных, ActiveRecord-style и не прилагали никаких усилий для контроля своих зависимостей. Тесная привязка доменных объектов к базе данных, чрезмерное использование статических методов и спагетти-подобная сеть зависимостей была большой частью того, что заставило эту кодовую базу стать преждевременно хрупким, негибким и непроверенным шаром грязи. Поэтому я думаю, что в то время как непрозрачные богатые объекты домена упрощают тестирование бизнес-логики, важно управлять вашими зависимостями.

Ответ 2

Я считаю, что анемиальный домен, в то время как анти-шаблон OO на самом деле является шаблоном SOA. Правила немного изменились, поскольку мы повысили уровень абстракции.

Я изучаю далее в серии, которую я пишу, у меня также был набросок об этом на моем журнале в прошлом году. metallemon.blogspot.com/2008/07/soa-and-anemic-domains.html

http://hubpages.com/hub/Building-Service-Orientated-Architecture

Ответ 3

Это именно то, что я не мог понять о том, что люди так волнуются о веб-сервисах. Не поймите меня неправильно, некоторые хорошие идеи есть, но я не вижу здесь никаких различий в процедурных программах. Посмотрите на свою архитектуру. То, что вы описываете, просто использует все материалы ООП, чтобы сделать его совершенно процедурным. Насколько проще было бы использовать простые структуры данных, алгоритмы и модули? Я не знаю вашу ситуацию, но подумайте, как проще использовать реляционную базу данных с хранимыми процедурами и некоторые привязки к веб-службам. Еще один ответ, кажется, со мной согласен каким-то образом... Я хотел бы услышать, что вы думаете, если это будет иметь больше смысла в вашей ситуации, и если не почему? Я ошибаюсь в процедурной природе веб-сервисов?

Ответ 4

Я предполагаю, что ваша архитектура основана на SOA и реализована с использованием обмена сообщениями, тогда модель домена должна находиться внутри вашего уровня обслуживания. Это означает, что нет необходимости заставлять всю архитектуру формироваться в модели домена, но вы можете применить ее в подструктуре.

Ответ 5

Я обнаружил, что большинство программистов просто не зарывают ООП. Когда он был представлен, все радовались тому, как мы больше не будем программировать еще одну структуру адресных данных и как эти классы будут вступать в брак с данными, чтобы нам не пришлось писать еще код проверки.

Затем, реальность, установленная в: Моя идея адреса не всегда jive с чужим. Хуже того, моя концепция адреса может измениться в зависимости от системы, с которой я сегодня работаю. И это простой.

И это стало еще хуже. Наследование? Что это? Абстрактные, виртуальные,... просто ключевые слова для ввода кода, чтобы закрыть компилятор.

И хуже: шаблоны кода. Нужно ли проверять объект? просто используйте этот вспомогательный шаблон здесь...

Итак, мы достигаем точки, в которой большинство людей считают, что "класс" является либо структурой, либо демпинговой базой для случайных функций, которые могут быть связаны каким-то образом, но не дай бог, чтобы вы поместили фактический код для класса с определенными данными им.

Ответ 7

Шесть лет спустя это требует значительного обновления.

Простой ответ - да. Но сложный ответ - нет.

Нет, SOA не требует анемии. Но в то же время корпоративная система не требуется писать с использованием SOA. И аналогичным образом архитектура не является обязательным требованием для любого кода. Это был бы кошмар, но вы могли бы упаковать каждый бит функциональности в один модуль, если хотите.

Проще говоря: OO первоначально определялось тем, как оно отличается от его предшественников. Более конкретно: С++ был определен тем, как он отличается от C. Но определение OO изменилось. Теперь у нас есть множество принципов ОО.

Отказ от ответственности: многие из этих принципов были частично или полностью созданы до OO и были просто заявлены или обновлены во время революции OO. Кроме того, я понимаю, что OO уже существует для LONG-Before С++, но это не меняет мое утверждение:

Инкапсуляция, наследование, полиморфизм, разделение проблем, сохранение невязки, высокая сцепление/низкая связь, S, O, L, I, D и многие другие.

Не только это, но если вы следуете DDD и/или TDD, следуя этим принципам, вам почти не нужно архитектовать вообще. Просто следуя этим принципам, вы, естественно, получаете сервис-ориентированную архитектуру, которая использует модели анемичных доменов.

Подумайте об этом. Если у вас есть класс Employee с Save(), SendMessage() и PayEmployee()... вы нарушаете так много правил текущих принципов OO.

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

Сортировка?

Честно говоря, вам нужно помнить об объектах Value. Не только определило определение OO, но также определило определение "Anemic". Класс Employee не должен быть пустым. В нем может быть много "бизнес-логики".

Класс Employee может иметь:

  • Параметрированный конструктор, в котором параметры проверяются
  • Readonly Properties, которые вычисляют поля
  • Employee.ToString(), Employee.TryParse() и аналогичные методы объекта
  • Возможно, другие, специфичные для Employee

В сущности, Сотрудник по-прежнему анемичен. никогда не будет никаких алгоритмов или логики кода в модели домена. Но существует не только один вид бизнес-логики.

Когда Мартин Фаулер сказал, что модели анемичных доменов были Anti-Pattern более десяти лет назад, он уже становился все более жизнеспособным. Его рассуждения были двоякими, и обе складки - старые новости.

Первая его первая сперва заключалась в том, что его защищающее определение OO заключалось в том, что Кодекс и данные были женаты или "объединять данные и обрабатывать вместе", против старого процедурного стиля. Это относится только к плохому коду, к сожалению. Если мы будем следовать Наследованию и Полиморфизму, мы знаем, что функции не ДЕЙСТВИТЕЛЬНО живут в классе. Они живут в указателях, так что классы наследования могут переопределять и перемещать их. Но... они живут в коде для повышения удобочитаемости? Они, конечно, не должны! Они должны быть определены в интерфейсах и абстракциях и реализованы только в классах. Извините Мартина, но пока вы были правильно, что брак Code/Data был огромным оригинальным пунктом продажи OO 2 десятилетия назад, теперь это не так важно.

Его вторая смена заключалась в том, что он дисквалифицировал SOA как выполненный неправильно и указывает на некоторые описания, которые очень напоминают то, что мы называем N-Tiered Architecture сегодня. Конечно, я понимаю, что это не новая технология, но определения менялись с годами.

Не только Мартин Фаулер, но и многие другие после него сразу же процитировали его статью, и поэтому сказал, что SOA сама по себе была анти-образцом, потому что ей нужны анемичные модели, которые, по словам Фаулера, являются Anti-Pattern.

Итак, мы дошли до этого...

Модели анемичных доменов на самом деле не так анемичны, как считают люди. И SOA требуется, мы не можем его обесценивать. К сожалению, это просто так, как есть.

Почему требуется SOA?. Это становится слишком описательным. Но длинный рассказ: в 90-х доменное программное обеспечение работало на ПК и серверах... и аппаратных "подключенных к этим" монолитам. В эти дни у нас буквально триллионы "компьютеров" вокруг нас. Детекторы дыма, Холодильники, Часы, Телефоны... В эти дни Компьютеры подключаются к вещам. Поэтому каждая идея, отдел, CONCERN и объект - это собственный небольшой домен. Мы требуем, чтобы SOA записывала их в свои небольшие сервисы и даже под-сервисы.

Поэтому: Приложения теперь подключаются к сервисам (вместо подключения к приложениям). Чтобы создать SOA, мы просто следуем текущим правилам OO, таким как SOLID и Разделение проблем. И когда мы это делаем, мы, естественно, приходим к моделям анемичных доменов... sorta.

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