Фреймворк Spring стал стандартом де-факто для создания Java-приложений корпоративного уровня.Многие корпоративные проекты построены на проекте Spring и его подпроектах, особенно веб-проекты Java, многие из которых используют Spring и следуют Web, Service, Dao This. принцип многоуровневости, нижний уровень предоставляет услуги верхнему уровню, однако Петри Кайнулайнен указал в своем блоге на самый большой недостаток многих веб-приложений Spring.
Большинство опытных программистов должны были слышать о DDD и попробовать его в своих проектах. Интересно, сталкивались ли вы когда-нибудь с таким сценарием: вы создали репозиторий (Repository), но через некоторое время обнаружили, что этот репозиторий все больше и больше похож на традиционный DAO, вы начинаете размышлять о собственной реализации, правильно ли это? Или вы создаете агрегат и обнаруживаете, что агрегат такой огромный, почему он ссылается на такое количество объектов, я опять что-то делаю не так?
В этой статье речь пойдет о проектировании, управляемом предметной областью, и использовании моделей анемии, кровопотери и перегрузки в проектировании, управляемом предметной областью.
Недостатки Spring-приложений
Большинство веб-приложений Java, использующих среду Spring, в настоящее время уделяют большое внимание принципу единой ответственности и принципу разделения задач, но, помимо этого, есть некоторые не очень хорошие анти-шаблоны и принципы проектирования, такие как :
- Объекты модели предметной области используются только для хранения данных приложения (модель предметной области использует антишаблон анемичной модели).
- Бизнес-логика находится на уровне службы и управляет данными объектов предметной области.
- На уровне обслуживания каждый объект приложения соответствует классу обслуживания.
Разработчики, создающие приложения с использованием Spring Framework, с удовольствием рассказывают о преимуществах внедрения зависимостей. Но, к сожалению, многие из них не используют свои преимущества, такие как принцип единой ответственности и разделение ответственности, в своих приложениях. Если вы внимательно посмотрите на веб-приложения на основе Spring, вы увидите, что многие из них реализованы с использованием этих распространенных и неправильных принципов проектирования:
Применение этого типа принципов проектирования очень обширно. Веб-проект Java, в котором я сейчас работаю, использует такие принципы проектирования для проектирования архитектуры. В основном это обычная трехуровневая или многоуровневая архитектура. На что они похожи?
- Веб-уровень (обычно известный как уровень представления, Presentation Layer): получает пользовательский ввод и передает данные на сервисный уровень;
- Уровень обслуживания (может называться уровнем бизнес-логики): граница транзакции, обрабатывает бизнес-логику, управление правами и авторизацию, а также взаимодействует с уровнем хранения;
- Уровень хранения (уровень доступа к данным): взаимодействует с базой данных и сохраняет данные.
Но ничего не нашли? Проблема кроется в сервисном уровне, на который возлагается слишком много обязанностей, таких как управление транзакциями, бизнес-логика, проверка разрешений и т. д., что нарушает принцип единой ответственности и разделения интересов, а также порождает большое количество зависимостей и циклических зависимостей. . При увеличении сложности бизнеса код, содержащийся в сервисном слое, будет очень большим и сложным, что напрямую приведет к увеличению затрат на тестирование. На сервисном уровне есть две основные проблемы:
- Бизнес-логика приложения исходит из сервисного уровня.
Бизнес-логика разбросана по сервисному уровню. Если нам нужно увидеть, как реализуется бизнес-правило, нам нужно сначала найти его. Кроме того, если существует несколько классов служб, для которых требуется одно и то же бизнес-правило, то это бизнес-правило копируется из одной службы в другую, что приводит к большому дублированию кода.
- Каждый класс модели предметной области имеет класс обслуживания на уровне обслуживания.
Это нарушает принцип единой ответственности: принцип единой ответственности гласит, что каждый класс должен иметь только одну ответственность, и эта ответственность должна быть полностью инкапсулирована классом. Все его услуги должны соответствовать этой ответственности.
Как улучшить статус-кво, ниже конкретно представлены соответствующие концепции и стратегии реализации доменно-ориентированного проектирования.
Дизайн, управляемый доменом (DDD)
Общая структура DDD разделена на четыре уровня: Инфраструктура (базовый уровень реализации), Домен (уровень домена), Приложение (прикладной уровень), Интерфейсы (уровень представления, также называемый уровнем пользовательского интерфейса или уровнем интерфейса). Функции каждого уровня описаны ниже.
- Пользовательский интерфейс (уровень представления): отвечает за представление информации пользователю и интерпретацию пользовательских команд.
- Уровень приложения: этот уровень координирует действия приложения. Не включает никакой бизнес-логики, не сохраняет состояние бизнес-объектов, но может сохранять состояние процесса задачи приложения.
- Уровень домена: этот уровень включает информацию о бизнес-домене. Здесь хранится состояние бизнес-объекта. Сохранение бизнес-объектов и их состояния может быть делегировано уровню инфраструктуры.
- Уровень инфраструктуры: этот уровень является вспомогательной библиотекой для других уровней. Он обеспечивает передачу информации между уровнями, реализует постоянство бизнес-объектов и включает вспомогательные библиотеки для уровня пользовательского интерфейса.
Базовые концепты
Организация
Когда объект отличается своей идентичностью (а не свойствами), такой объект называется сущностью. Например, когда два объекта имеют разные идентификаторы, даже если другие свойства двух объектов одинаковы, мы считаем их двумя совершенно разными сущностями.
Объект значения
Когда объект используется для описания чего-либо без уникальной идентификации, он называется объектом-значением. Потому что в полевых условиях не всегда вещь должна иметь уникальный идентификатор, то есть нам все равно, что это за вещь, важно, что это за вещь. Например, в процессе заказа для адреса доставки, если информация об адресе одинакова, мы считаем, что это один и тот же адрес доставки. Мы также не можем сказать «этот» объект-значение или «тот» объект-значение, потому что у него нет уникального идентификатора.
Служба домена
Некоторые важные поведения или операции предметной области не подходят для моделирования в качестве объектов-сущностей или объектов-значений. По сути, это просто некоторые операции, а не конкретные вещи. С другой стороны, эти операции часто включают операции нескольких объектов предметной области. для координации этих объектов домена для выполнения операций, мы можем классифицировать их как службы домена. Он реализует всю бизнес-логику и обеспечивает корректность бизнеса с помощью различных методов проверки. В то же время он также может избежать логики предметной области на прикладном уровне. Чтобы понять, служба домена — это что-то вроде фасада.
Совокупный и совокупный корень (агрегат, совокупный корень)
Агрегация предназначена для достижения целостности модели предметной области путем определения четких отношений принадлежности и границ между объектами предметной области, чтобы избежать образования сложных и сложных в обслуживании сетей объектных отношений. Агрегат определяет набор связанных объектов предметной области со связанными отношениями, и мы можем думать о агрегате как о единице, которая изменяет данные.
Совокупный корень принадлежит объекту сущности, который является высоко связанным основным объектом в объекте предметной области. (Корень агрегата имеет глобальный уникальный идентификатор, в то время как сущность имеет только уникальный локальный идентификатор внутри агрегата, а объект-значение не имеет уникального идентификатора. Не существует такой вещи, как этот объект-значение или этот объект-значение)
Если агрегат имеет только одну сущность, то эта сущность является корнем агрегата, но если сущностей несколько, нам нужно подумать о том, какой объект в совокупности имеет самостоятельное значение и может напрямую взаимодействовать с внешними полями.
Фабрика
Фабрика в DDD также является отражением идеи инкапсуляции. Причина введения фабрик в том, что иногда создание объекта предметной области является относительно сложной задачей, а не простой новой операцией. Роль фабрики заключается в том, чтобы скрыть детали создания объекта. На самом деле, в большинстве случаев создание объектов предметной области не является относительно сложным, поэтому для создания объектов нам нужно использовать только простые конструкторы. Преимущество сокрытия деталей создания объектов очевидно, так что бизнес-логика доменного уровня не будет просачиваться на прикладной уровень, и в то же время будет снижена нагрузка на прикладной уровень. просто вызовите фабрику доменов, чтобы создать нужный объект.
Репозиторий
Репозитории ресурсов инкапсулируют инфраструктуру для предоставления операций запросов и постоянных агрегатных операций. Это позволяет нам всегда фокусироваться на уровне модели и делегировать хранение и доступ к объектам в репозиторий. Это не инкапсуляция базы данных, а мост между доменным уровнем и инфраструктурой. DDD касается модели в домене, а не работы базы данных.
ДДД дизайн
Концепция DDD немного абстрактна для понимания.Это немного похоже на шаблон проектирования, и кажется очень полезным, но когда я разрабатываю его сам, я не знаю, как применить его к коду, или это выглядит неуклюжим. когда я использую его механически. Стратегический дизайн DDD в основном включает такие понятия, как домен/поддомен, общий язык, ограниченный контекст и архитектурный стиль.
Домены и поддомены
В реальном мире домен содержит проблемную область и систему решений. Программное обеспечение обычно считается частичной симуляцией реального мира. В DDD система решений может быть отображена в ограниченный контекст, а ограниченный контекст — это конкретное и ограниченное решение программного обеспечения в предметной области.
В повседневной разработке мы обычно разбиваем большую программную систему на несколько подсистем. Это разделение может основываться на архитектурных соображениях или на инфраструктуре. А вот в DDD мы делим систему по домену, то есть по бизнесу.
ограниченный контекст
Конкретная ответственность, ограниченная явной границей. Модель предметной области существует в пределах этой границы. Внутри границы каждое понятие модели, включая ее свойства и операции, имеет особое значение.
Объединяя все понятия в ограниченном контексте, включая существительные, глаголы и прилагательные, мы создаем общий язык для этого ограниченного контекста. Лингва-франка — это язык, на котором общаются все члены команды, и бизнес-аналитики, программисты и тестировщики должны общаться напрямую через лингва-франка.
Для проблемы интеграции между различными подобластями, упомянутыми выше, это фактически проблема интеграции между ограниченными контекстами. При интеграции нас больше всего интересует взаимосвязь между моделью предметной области и средствами интеграции. Например, для интеграции с ресурсом REST вам необходимо предоставить инфраструктуру (например, RestTemplate в Spring), но эти средства не являются частью вашей основной модели предметной области. Что вам следует делать? Ответ — антикоррупционный слой, который отвечает за взаимодействие с внешними поставщиками услуг и за преобразование внешних концепций в концепции, понятные их основному домену. Конечно, антикоррозийный слой — это только один из многих методов интеграции между ограниченными контекстами, есть также общие ядра, открытые хост-сервисы и т. д. Подробности можно найти в оригинальной книге «Реализация доменно-управляемого проектирования». Интеграционное отношение между ограниченными контекстами также можно понимать как отношение сопоставления между понятиями предметной области в разных контекстах, поэтому интеграцию между ограниченными контекстами также называют контекстной картой.
резюме
В этом документе приведены меры по улучшению с помощью недостатков веб-приложения Spring, а затем представлены связанные концепции и стратегии проектирования доменно-ориентированной разработки. Впереди было сказано так много концепций, что, по-видимому, у читателей должно возникнуть желание понять, как реализовать дизайн, ориентированный на предметную область. В следующей статье автор представит несколько типов моделей предметной области и конкретные практические случаи DDD.