![Модель Анемичного Домена [Перевод]](/assets/images/logos/logo-white.webp "Модель Анемичного Домена [Перевод]"){kind=logo}
В разгар моего увлеченного изучения DDD я прочитал статью Мартина Фаулера от 25 ноября 2003 г.Теги: #ddd #Анемичная доменная модель #анемичная модель #проектирование и рефакторингМодель анемичного домена .
Иногда для лучшего понимания материала я перевожу его на русский язык.
Вот я и решил поделиться переводом.
Перевод авторский и местами очень осмысленный.
Ссылка к оригинальный .
В статье приведены цитаты из уже вышедшей книги, переведенной на русский язык профессионалами.
Чтобы улучшить понимание моего перевода, я привел цитаты из книги под спойлерами.
Модель бледного домена Это один из тех антипаттернов, который окружал нас уже давно, а сейчас проявляет себя еще активнее.
Я говорил об этом с Риком Вэнсом, и мы оба отметили, что он становится все более популярным.
И я, как сторонник правильной Доменной Модели, считаю, что это нехорошо.
Первые симптомы модели Бледного домена заключаются в том, что она выглядит нормально, но только на первый взгляд. Объекты называются существительными из предметной области, связаны между собой и имеют структуру, как обычные предметы предметной области.
Понимание приходит при просмотре их содержания; это не что иное, как набор геттеров и сеттеров.
Часто эти объекты предметной области имеют архитектурные правила, запрещающие размещать в них какую-либо логику предметной области.
Вместо этого существует набор сервисов (объектов сервисов), которые содержат всю логику предметной области.
Эти сервисы архитектурно расположены на уровне выше модели предметной области и используют ее в качестве источника данных.
Ужас этого антипаттерна в том, что он противоречит основной идее объектно-ориентированного проектирования, которая заключается в объединении данных и процесса (поведения).
Бледная модель — это что-то вроде процедурного дизайна, именно то, с чем такие компьютерщики, как я и Рик, боролись с самых первых дней нашего знакомства со Smalltalk. В наши дни объектно-ориентированный пуризм — это хорошо, но я думаю, что нужны более убедительные аргументы против этой «бледности» модели.
Проблема с моделью предметной области Пэйла в том, что она несет на себе все бремя модели предметной области, не принося при этом ее преимуществ.
И мы платим за это абсурдностью сопоставления базы данных, что обычно приводит к созданию целого слоя ORM. Это имеет смысл только тогда, когда для организации сложной логики используются мощные объектно-ориентированные методы.
Однако, перенося все поведение системы в сервисы, нужно понимать, что все закончится плохо.
Скрипт транзакции 'ami, и вы, конечно, потеряете все преимущества, которые дает модель предметной области.
Но, как я сказал в книге П Е.
А.
А.
Модель предметной области не всегда является лучшим выбором.
Также стоит отметить, что размещение поведения в объектах предметной области не должно противоречить единообразному подходу использования слоев для отделения логики предметной области от уровня персистентности и представления.
Логика, которая должна быть в объекте предметной области, — это логика предметной области, например: проверка, вычисления или то, что вы называете «бизнес-правилами».
(Конечно, бывают случаи, когда вы передаете источник данных или части логики представления объекту предметной области через параметр, но это ортогонально моему представлению о «боли».
) Одним из источников неправильного толкования является то, что многие объектно-ориентированные эксперты рекомендуют размещать уровень процедурных сервисов.
выше модель предметной области для формирования уровня обслуживания.
Но это не аргумент в пользу того, чтобы не помещать поведение в предметную модель; Фактически, уровень обслуживания поощряет его использование в сочетании с моделью предметной области, содержащей поведение.
Отличная книга Рика Вэнса Проектирование, ориентированное на предметную область Об этих слоях говорится следующее.
Уровень приложения [так он называет уровень обслуживания]: определяет задачи, которые должно решать приложение, и направляет их выполнение в (богатую) модель предметной области.Из книгиЗадачи этого уровня значимы для бизнеса (не бизнес-логики) или представляют собой просто взаимодействие с прикладным уровнем других систем.
Этот слой должен оставаться тонким.
Он не содержит бизнес-логики или каких-либо знаний, он лишь координирует задачи и делегирует работу наборам объектов предметной области на более низком уровне.
Он не несет в себе состояние, которое бы отражало ситуацию в бизнес-логике, но может знать о состоянии выполнения задачи, чтобы информировать пользователя и/или приложение в целом.
Определяет задачи, которые должна решить проблема, и распределяет их по объектам, выражающим сущность предметной области.Задачи, выполняемые этим уровнем, имеют смысл для пользователя-специалиста или необходимы для интерактивного взаимодействия с операционными уровнями других систем.
Этот уровень не нужно «раздувать» в размерах.
Он не содержит ни знаний, ни бизнес-правил, а лишь координирует задачи и распределяет работу между множествами объектов предметной области на следующем, более низком уровне.
Он не отражает состояние объектов модели приложения, но может содержать состояние, которое информирует пользователя о ходе выполнения задачи.
Уровень предметной области (или уровень модели): отвечает за представление смысла бизнес-процессов, несет информацию о бизнес-ситуации и бизнес-правилах (бизнес-логике).Из книгиЗдесь контролируется и используется состояние, отражающее ситуацию в приложении (в его бизнес-части), даже если технические детали хранения (персистентности) данных делегируются инфраструктуре.
Этот уровень является сердцем приложения.
Отвечает за представление концепций прикладной предметной области, рабочих состояний и правил ведения бизнеса.Дело в том, что уровень обслуживания тонкий , и вся логика находится на уровне домена.Здесь контролируется и используется текущее состояние модели приложения, хотя технические детали манипулирования данными делегируются инфраструктуре.
Этот уровень является основной, алгоритмической частью программы.
Он (Эрик) повторяет это в своем шаблон услуги
В настоящее время распространенной ошибкой является слишком ранний отказ от помещения поведения в соответствующий объект, постепенно скатывающийся к процедурному программированию.Из книги
На этом этапе легко совершить распространенную ошибку: отказаться от попыток поместить операцию в подходящий для нее объект и, таким образом, перейти к процедурному программированию.Я не знаю, почему этот антипаттерн возникает так часто.
Я подозреваю, что это потому, что очень много людей, которые не работали с правильный модель предметной области, особенно если они происходят из мира данных.
Некоторые технологии поощряют этот антишаблон, например Entity Beans J2EE, и это одна из причин, почему я предпочитаю ПОДЖО модели предметной области.
В общем, чем больше логики в ваших сервисах, тем больше похоже, что вы остались без преимуществ модели предметной области.
А если вся твоя логика в сервисах, то ты тупо себя ограбил.
Спасибо за внимание.На приглашение не претендую, так как оно мне не нужно.
Но если кто-то считает, что материал достоин инвайта, просто дайте мне знать в комментариях, мне будет приятно.
-
Слово
19 Oct, 24 -
Для Тех, Кто Выбирает Межсетевой Экран
19 Oct, 24 -
Универсальная Админ-Панель
19 Oct, 24
