Шесть лет спустя, это требует серьезного обновления.
Простой ответ - да. Но сложный ответ - нет.
Нет, SOA не требует анемии. Но в то же время корпоративная система не должна быть написана с использованием SOA. И точно так же архитектура не является обязательным требованием для любого кода. Это был бы кошмар, но вы могли бы упаковать каждый бит функциональности в один модуль, если хотите.
Проще говоря: ОО изначально определялся тем, как он отличался от своих предшественников. Более конкретно: C ++ определялся тем, как он отличался от C. Но определение ОО изменилось. Теперь у нас есть множество ОО Принципов.
Отказ от ответственности: многие из этих принципов были частично или полностью созданы до ОО и были просто востребованы или обновлены во время ОО-революции. Кроме того, я понимаю, что ОО был для LONG-Before C ++, но это не меняет мое утверждение:
Инкапсуляция, Наследование, Полиморфизм, Разделение проблем, Невосприимчивость к постоянству, Высокая сплоченность / Низкая связь, S, O, L, I, D и многие другие.
Не только это, но если вы следуете DDD и / или TDD, следуя этим принципам, вам почти не придется создавать архитектуру вообще. Просто следуя этим принципам, вы естественным образом получаете сервис-ориентированную архитектуру, в которой используются анемичные доменные модели.
Подумай об этом. Если у вас есть класс Employee с Save(), SendMessage() и PayEmployee() ..., вы нарушаете так много правил действующих Принципов ОО.
Когда вы анализируете и распределяете определенные обязанности в различных службах, хранилищах, командах, фабриках и т. Д. ... Вы не можете помочь , но у вас есть пустой класс сотрудника ... вроде.
Вроде?
Честно говоря, вам нужно помнить идею объектов значения. Понятие ОО не только эволюционировало, но и понятие «Анемия» также эволюционировало. Класс Employee, безусловно, не должен быть пустым. В нем может быть много «бизнес-логики».
Класс Employee может иметь:
- Параметризованный конструктор, где параметры проверяются
- Только для чтения Свойства, вычисляющие поля
- Employee.ToString (), Employee.TryParse () и аналогичные методы объекта
- Возможно, другие, специфичные для сотрудника
По сути, Сотрудник все еще страдает анемией. , конечно, никогда не будет никаких алгоритмов или логики потока кода в модели предметной области. Но не существует только одного вида бизнес-логики.
Когда Мартин Фаулер сказал, что модели анемичных доменов были анти-паттерном более десяти лет назад, он уже становился все более и более жизнеспособным. Его рассуждение было двояким, и оба раза - старые новости.
Его первым сгибом было то, что его защитное определение ОО состояло в том, что Код и Данные были женаты или «объединяли данные и обрабатывали вместе», в отличие от старого процедурного стиля. К сожалению, это верно только для плохого кода. Если мы следуем Наследованию и Полиморфизму, мы знаем, что функции ДЕЙСТВИТЕЛЬНО не живут в классе. Они живут по указателям, так что наследующие классы могут переопределять и перемещать их. Но ... они живут в коде, чтобы улучшить читаемость? Они, конечно, не должны! Они должны быть определены в интерфейсах и абстракциях и реализованы только в классах. Извините, Мартин, но в то время, как вы были правы, брак по коду / данным был огромным оригинальным аргументом в пользу ОО 2 десятилетия назад, но сейчас это не так уж и много.
Его второе замечание состояло в том, что он дисквалифицирует SOA как неправильно выполненную и указывает на некоторые описания, которые очень похожи на то, что мы сегодня называем N-Tiered Architecture. Конечно, я понимаю, что это не новая технология, но определения менялись с годами.
Не только Мартин Фаулер, но и многие другие после него немедленно цитировали его статью и поэтому заявили, что SOA сама по себе является анти-паттерном, потому что она требует анемичных моделей, что, по словам Фаулера, является анти-паттерном.
Итак, мы до этого ...
Анемичные доменные модели на самом деле не такие анемичные, как полагают люди. И SOA требуется, мы не можем сбрасывать со счетов это. К сожалению, это просто так.
Почему требуется SOA? - Это слишком наглядно. Но короткая история: в 90-х годах доменное программное обеспечение работало на ПК и серверах ... и аппаратное обеспечение "подключено" к этим монолитам. В наши дни вокруг нас буквально триллионов"компьютеров". Детекторы дыма, холодильники, часы, телефоны ... В наши дни Компьютеры подключаются к вещам . Таким образом, каждая идея, отдел, CONCERN и объект - это свой маленький домен. Мы требуем, чтобы SOA записывал их в свои собственные маленькие сервисы и даже подуслуги.
Следовательно: приложения теперь подключаются к службам (вместо служб подключаются к приложениям). Чтобы создать SOA, мы просто следуем действующим правилам OO, таким как SOLID и Разделение проблем. И когда мы делаем это, мы естественным образом получаем модели анемичных доменов ... Сорта.
Так что нет, анемичные доменные модели не требуются для SOA. Они являются естественным результатом следования действующим принципам и стандартам.