Действительно ли доменная Анемия является соответствующей в Сервис-ориентированной архитектуре?
Я хочу быть ясным на этом. Когда я говорю, что доменная анемия, имею в виду намеренную доменную анемию, не случайную. В мире, где большая часть нашей бизнес-логики скрыта позади набора сервисов, полная модель предметной области действительно необходима?
Это - вопрос, который я должен был задать сам недавно начиная с работы над проектом, где "доменная" модель является в действительности моделью персистентности; ни один из объектов области не содержит методов, и это - очень намеренное решение.
Первоначально, я дрожал, когда я видел библиотеку, полную того, что является чрезвычайно безопасными с точки зрения типов контейнерами данных, но после того, как некоторые думали, что она ударила меня, что эта конкретная система не делает многого, но основных операций CRUD, поэтому возможно, в этом случае это - хороший выбор. Моя проблема, которую я предполагаю, состоит в том, что мой опыт до сих пор был очень сфокусирован на богатой модели предметной области, таким образом, он бросил меня немного.
Остаток от доменной логики скрыт в группе помощников, фасадов и фабрик, которые живут в отдельном блоке.
Я стремлюсь услышать, какие мысли людей находятся на этом. Очевидно, соображения для повторного использования этих классов намного более просты, но действительно что большой преимущество?
6 ответов
Я согласен, что полная модель предметной области может не понадобиться. Однако я думаю, что писать тесты для сервисов с имитируемыми объектами доступа к данным труднее, чем писать тесты для не анемичных доменных объектов. Сейчас я работаю над проектом, в котором логика предметной области существует повсюду, кроме модели предметной области, разбросана по помощникам, стратегиям и посредникам, и все это превратилось в неуправляемую кучу устаревшего кода еще до того, как он попал в производство.
Вспоминая предыдущие проекты, я действительно помню один, в котором использовались анемичные доменные объекты, у него было много проблем, в том числе ужасная самодельная база данных xml, но, поскольку он основывался на сервисном подходе, было легко решить проблемы по одному и добиться реального прогресса. В текущем проекте они постарались проявить смекалку и привязать объекты домена к базе данных в стиле ActiveRecord и не предприняли никаких попыток контролировать их зависимости. Тесная связь объектов предметной области с базой данных, чрезмерное использование статических методов и похожая на спагетти сеть зависимостей - большая часть того, что привело к тому, что эта кодовая база превратилась в преждевременно хрупкий, негибкий и непроверенный комок грязи. Поэтому я думаю, что, несмотря на то, что богатые объекты домена, игнорирующие персистентность, значительно упрощают тестирование бизнес-логики, важно управлять своими зависимостями.
Я полагаю, ваша архитектура основана на SOA и реализована с использованием обмена сообщениями, тогда модель предметной области должна находиться внутри вашего уровня сервиса. Это означает, что нет необходимости принудительно формировать всю архитектуру в модель предметной области, но вы можете применить это в подархитектуре.
Я обнаружил, что большинство программистов просто не понимают ООП. Когда он был представлен, все обрадовались тому, что мы больше не будем программировать еще одну структуру данных адреса и как эти классы будут связывать код с данными, чтобы нам не пришлось писать дополнительный код проверки.
Затем наступила реальность: мое представление об адресе не всегда совпадает с чьим-то другим. Хуже того, мое представление об адресе может меняться в зависимости от системы, над которой я работаю сегодня. И это очень просто.
И стало еще хуже. Наследование? Что это такое? Абстрактные, виртуальные, ... просто ключевые слова, которые нужно вставить в код, чтобы выключить компилятор.
И что еще хуже: шаблоны кода. Нужно проверить объект? просто используйте этот вспомогательный шаблон здесь ...
Итак, мы подошли к точке, где большинство людей считает, что «класс» - это либо структура, либо свалка для случайных функций, которые могут быть связаны в некоторых Кстати, но не дай бог поставить актуальный код для класса с определенными им данными.
Это именно то, чего я не мог понять в людях, которые так увлечены веб-сервисами. Не поймите меня неправильно, есть несколько хороших идей, но я не вижу здесь разницы с процедурным программированием. Посмотри на свою архитектуру. То, что вы описываете, - это просто использование всего ООП, чтобы сделать его идеально процедурным. Насколько проще было бы использовать простые структуры данных, алгоритмы и модули? Я не знаю вашей ситуации, но подумайте, насколько проще было бы использовать реляционную базу данных с хранимыми процедурами и некоторыми привязками к веб-службам. Еще один ответ, кажется, в некотором роде со мной согласуется ... Я хотел бы услышать, что вы думаете, будет ли это иметь больше смысла в вашей ситуации, а если нет, почему? Я ошибаюсь насчет процедурной природы веб-сервисов?
Я считаю, что анемичный домен в то время как объектно-ориентированный антишаблон на самом деле является шаблоном SOA. Правила немного изменились, поскольку мы повысили уровень абстракции.
Я продолжаю исследование в серии, которую пишу, я также разглагольствовал об этом в моем журнале в прошлом году. metallemon.blogspot.com/2008/07/soa-and-anemic-domains.html
http://hubpages.com / hub / Building-Service-Orientated-Architecture