Прогнозируется, что архитектура микросервисов и проектирование, управляемое предметной областью (DDD), продолжат набирать значительную популярность в разработке программного обеспечения. Сочетание этих мощных подходов позволяет командам создавать масштабируемые, удобные в обслуживании и ориентированные на бизнес системы.
В этой статье мы рассмотрим ключевые принципы и этапы разработки микросервисов, ориентированных на DDD, что позволит вам использовать преимущества обеих парадигм. Давайте углубимся в эти концепции, используя Бит в качестве ссылки.
Что такое доменно-ориентированное проектирование (DDD)?
Domain-Driven Design (DDD) — это подход к разработке программного обеспечения, в котором основное внимание уделяется моделированию программного обеспечения на основе предметной области, которую оно обслуживает. Это включает в себя понимание и моделирование предметной области или проблемной области приложения, способствуя тесному сотрудничеству между экспертами в предметной области и разработчиками программного обеспечения. Это сотрудничество создает общее понимание предметной области и гарантирует, что разработанное программное обеспечение тесно связано с ее тонкостями.
Что такое микросервисы?
С другой стороны, микрослужбы — это архитектурный стиль, который организует приложение в виде небольших, слабо связанных и независимо развертываемых служб. Каждая микрослужба предназначена для определенных бизнес-возможностей и может разрабатываться, развертываться и масштабироваться независимо. Они способствуют модульности, масштабируемости и гибкости в разработке программного обеспечения.
Почему мы должны сочетать DDD с микросервисами?
Сочетание DDD с архитектурой микросервисов может быть очень полезным для создания сложных, масштабируемых и удобных в сопровождении программных систем. DDD и микросервисы дополняют друг друга и затрагивают различные аспекты разработки программного обеспечения, образуя мощную комбинацию. Вот основные причины, по которым выгодно сочетать DDD с микросервисами:
- Ограниченные контексты и границы микрослужб. DDD вводит концепцию ограниченных контекстов, которая определяет границы модели предметной области и инкапсулирует ее логику. Эти ограниченные контексты хорошо согласуются с идеей микросервисов, где каждый микросервис представляет определенный ограниченный контекст. Такое согласование помогает определить четкие и независимые обязанности для каждого микросервиса, способствуя лучшей модульности и разделению задач.
- Децентрализованное управление данными. В микросервисах каждый сервис отвечает за свои данные. Акцент DDD на агрегатах, сущностях и объектах-значениях поощряет децентрализованный подход к управлению данными, при котором каждый микросервис имеет свое хранилище данных, соответствующее его ограниченному контексту. Такая изоляция данных соответствует принципам DDD и повышает автономию службы.
- Разработка на основе модели. DDD способствует глубокому пониманию предметной области и ее сложностей. Применяя DDD, разработчики могут создать богатую модель предметной области, которая отражает тонкости предметной области. Этот основанный на модели подход гарантирует, что каждый микросервис имеет четко определенную и ориентированную на предметную область цель, что приводит к созданию более удобной в сопровождении и выразительной системы.
- Повсеместный язык. DDD выступает за использование универсального языка, который используется экспертами в предметной области и разработчиками. В сочетании с микросервисами вездесущий язык способствует лучшему общению между командами, ответственными за разные микросервисы. Это обеспечивает общее понимание концепций предметной области и способствует сотрудничеству.
- Масштабируемость и слабая связь. Микросервисы обеспечивают внутреннюю масштабируемость благодаря своей децентрализованной природе. Акцент DDD на определении агрегатов и ограниченных контекстов позволяет микросервисам быть независимо масштабируемыми, уменьшая зависимости и способствуя слабой связи между сервисами.
- Эволюционная архитектура. И DDD, и микросервисы поддерживают эволюционную архитектуру. DDD позволяет модели предметной области развиваться вместе с меняющимися бизнес-требованиями, а модульная природа микросервисов позволяет отдельным сервисам развиваться независимо, не затрагивая всю систему.
- Непрерывная доставка и развертывание. Небольшие и независимые кодовые базы микросервисов способствуют более быстрому и более частому развертыванию. Акцент DDD на четких границах и модульной структуре гарантирует, что изменения в одном микросервисе окажут минимальное влияние на другие, что упрощает непрерывную доставку и развертывание.
- Автономия команды. Соединяя микросервисы с ограниченными контекстами, команды могут взять на себя ответственность за отдельные микросервисы, способствуя автономии команды. Каждая команда может сосредоточиться на своей конкретной области и эффективно реализовать бизнес-логику, что приведет к повышению производительности.
Хотя сочетание DDD и микросервисов дает много преимуществ, важно отметить, что реализация обоих подходов требует тщательного рассмотрения и понимания предметной области. Создание успешной системы с использованием DDD и микросервисов требует совместных усилий экспертов в предметной области, разработчиков и заинтересованных сторон для создания хорошо спроектированной, масштабируемой и удобной в сопровождении архитектуры.
Как микросервисы вписываются в методологию DDD?
DDD выделяет программное обеспечение для моделирования в зависимости от области, которую оно обслуживает.
Мы исследуем основные концепции DDD, включая ограниченные контексты, агрегаты, сущности, объекты-значения и доменные службы. Понимая эти принципы, вы сможете эффективно определять границы своих микросервисов и разрабатывать их в соответствии с сферами бизнеса, которые они представляют.
Давайте углубимся в ключевые принципы и этапы разработки микросервисов, ориентированных на DDD, на примере приложения для электронной коммерции.
Внедрение микросервисов, ориентированных на DDD
Архитектура микрослужб предлагает способ структурировать приложение как набор слабо связанных служб, где каждая служба работает независимо в своем процессе и взаимодействует с помощью упрощенных механизмов. В нашем примере с электронной коммерцией каждый ограниченный контекст может быть реализован как отдельный микросервис.
Например, у нас могут быть микросервисы, посвященные «Управлению заказами», «Каталогу продуктов», «Обработке платежей» и «Управлению пользователями». Bit поддерживает этот подход, предоставляя инструменты для создания микросервисов и управления ими посредством разработки на основе компонентов.
1. Понимание домена
В DDD начальный шаг включает в себя полное понимание предметной области. Это требует сотрудничества с экспертами в предметной области для определения важнейших бизнес-концепций, отношений и поведения.
В нашем примере [основной домен] (общие субдомены) может быть «Каталог продуктов». Эта сущность служит фундаментальным строительным блоком нашей системы, инкапсулируя поведение и состояние. Как показано на изображении выше, каталог товаров помечен как «основной субдомен», представляющий собой основную часть домена. В этом случае, потому что это то, с чем будут взаимодействовать клиенты. Другие поддомены были классифицированы как вспомогательные и общие.
Чтобы облегчить этот шаг, Bit предлагает платформу для совместной работы, на которой эксперты в предметной области и разработчики могут совместно определять и документировать модели предметной области, фиксировать бизнес-правила и делиться знаниями. Функции совместной работы Bit, включая общие рабочие области, контроль версий и поддержку документации, способствуют эффективному общению и обмену знаниями между экспертами в предметной области и разработчиками.
Источник: https://bit.cloud/bit/evangelist/sections/build-together?example=5ee51e53c166fb0019182a29
Поддомены поддержки функционируют как вспомогательные домены в рамках всей системы. На практике вы определяете для них ограниченный контекст и создаете специальное приложение, которое служит системой поддержки для приложения основного домена. Несмотря на поддержку, эти приложения поддерживают свою собственную модель.
С другой стороны, [Общие субдомены] (Общие субдомены) имеют сходство с субдоменами поддержки, но имеют существенную разницу. Они предлагают настолько универсальные решения, что их можно использовать не только в пределах конкретного Домена, для которого они были созданы, но и в других Доменах. Например, хорошо спроектированное «Приложение для контроля доступа» можно легко перепрофилировать для поддержки доменов, выходящих за рамки электронной коммерции. Именно поэтому они называются общими субдоменами».
2. Ограниченные контексты
В доменно-управляемом дизайне (DDD) домен делится на ограниченные контексты, которые действуют как логические границы, инкапсулирующие определенные доменные области. Каждый ограниченный контекст представляет собой отдельную подсистему в приложении.
Микросервисы гармонично сочетаются с ограниченными контекстами в DDD, поскольку они предлагают естественный подход к реализации и развертыванию каждого контекста как отдельного сервиса.
В нашем приложении электронной коммерции у нас могут быть ограниченные контексты, такие как «Заказ», «Каталог продуктов», «Оплата», «Запасы», «Отправка» и «Аутентификация и авторизация управления пользователями». Bit упрощает предоставление инструментов для определения и управления границами ограниченных контекстов. На приведенной ниже диаграмме показаны основные контексты приложения электронной коммерции. Благодаря подходу Bit к разработке, основанному на компонентах, разработчики могут инкапсулировать функциональность каждого ограниченного контекста и управлять им как независимыми компонентами. Эти компоненты впоследствии могут быть развернуты как микросервисы.
3. Совокупный дизайн
Агрегаты служат границами согласованности в домене, инкапсулируя кластеры связанных сущностей и объектов-значений. Они гарантируют согласованность данных и устанавливают четкие границы для соблюдения бизнес-правил.
- Как принять решение об агрегатах?
Выбор агрегатов в DDD включает в себя определение границ согласованности и целостности транзакций в рамках модели предметной области. Агрегаты — это кластеры связанных сущностей и объектов-значений, которые рассматриваются как единое целое, гарантируя, что изменения в одной части агрегата сохранят согласованность целого.
- Существуют ли ключевые характеристики, определяющие агрегат?
Да, есть ключевые характеристики, которые определяют совокупность в DDD. Агрегат — это фундаментальный строительный блок в DDD, представляющий связную единицу объектов предметной области, которые рассматриваются как единый объект с четко определенными границами. Вот ключевые характеристики, которые определяют совокупность:
- Граница согласованности. Агрегат представляет собой границу согласованности в домене. Агрегат гарантирует, что состояние его внутренних объектов остается согласованным и действительным.
- Корень агрегата. У каждого агрегата есть назначенный «корень агрегата», который действует как точка входа в агрегат.
- Граница транзакции. Изменения в совокупности вносятся в рамках одной транзакции. Весь агрегат обрабатывается как единая единица работы, гарантируя, что либо все изменения будут успешными, либо не будет вообще никаких изменений.
- Инкапсуляция. Внутренняя структура агрегата скрыта от внешних сущностей.
- Применение инварианта. Агрегаты применяют инварианты, то есть правила и ограничения, которые должны выполняться внутри агрегата. Инварианты гарантируют, что агрегат остается в допустимом и согласованном состоянии во время и после любой операции.
- Управление жизненным циклом. Агрегаты управляют жизненным циклом своих внутренних объектов. Например, создание, обновление и удаление сущностей и объектов-значений должно выполняться через корень агрегата, который сохраняет контроль над этими действиями.
- Граница для связи. Агрегаты служат в качестве границ для связи и согласованности между различными частями модели предметной области. Изменения в одном агрегате не влияют напрямую на другие агрегаты, что помогает поддерживать модульность и уменьшать связанность.
- Дробность. Агрегаты должны иметь надлежащую степень детализации, то есть они не должны быть ни слишком большими, ни слишком маленькими. Они должны быть разработаны для управления осмысленным набором связанных концепций и операций предметной области.
Понимание и соблюдение этих ключевых характеристик агрегатов имеет решающее значение для успешного применения принципов DDD и построения хорошо структурированных моделей предметной области в сложных программных системах.
В DDD микросервисы могут согласовываться с агрегатами, реализуя каждый агрегат как отдельный микросервис. В нашем примере агрегат «Заказ» может содержать такие объекты, как «Элемент заказа», «Клиент» и «Адрес доставки».
Бит облегчает этот процесс, предлагая инструменты для проектирования и управления агрегатами как многократно используемыми компонентами. Разработчики могут определять агрегаты как компоненты в Bit и использовать его функции управления версиями и зависимостями для обеспечения согласованности и модульности микросервисов.
## 4.Общение и интеграция
Связь и интеграция между службами жизненно важны в архитектуре микрослужб. Службы должны взаимодействовать и обмениваться информацией для выполнения бизнес-процессов.
5. Развертывание и масштабирование
Преимущество микрослужб заключается в независимом развертывании и масштабировании, что позволяет развертывать и масштабировать каждую микрослужбу индивидуально в соответствии с ее конкретными требованиями. Эта гибкость и масштабируемость имеют решающее значение в современной разработке программного обеспечения.
Заключение
В заключение, разработка микросервисов, ориентированных на DDD, требует всестороннего понимания как принципов DDD, так и архитектуры микросервисов.
Применяя DDD, идентифицируя ограниченные контексты и согласовывая микросервисы с агрегатами, вы можете создавать системы, которые являются масштабируемыми, удобными в сопровождении и полностью соответствуют потребностям вашего бизнеса. Крайне важно постоянно повторять и совершенствовать свою архитектуру, используя опыт предметной области и отзывы. Этот итеративный подход гарантирует, что ваши микросервисы будут развиваться и адаптироваться с течением времени в соответствии с меняющимися потребностями вашего бизнеса. Объединив возможности DDD и микросервисов, вы можете создавать надежные и адаптируемые программные системы, которые будут способствовать развитию вашей организации.
