Дизайн, управляемый доменом, основанный на дизайне микросервисной архитектуры

Микросервисы Дизайн, управляемый доменом

задний план

Сейчас можно сказать, что микросервисы — это тема, которую никто не упоминает в области исследований и разработок программного обеспечения, однако большинство популярных сравнений в отрасли — это так называемые монолиты (одно приложение), и большое количество системы были распределенными системами, основанными на SOA (сервисно-ориентированной архитектуре) более десяти лет назад, так в чем же разница между микросервисами как новым стандартом архитектуры и SOA? Существенная разница заключается в принципе проектирования: микросервис — это децентрализованный дизайн, а SOA — это «интеграция» для формирования центрального дизайна;

Кроме того, автор считает, что следующие моменты не являются отличием микросервисов от SOA:

  • CI/CD: непрерывная интеграция и непрерывное развертывание переплетаются с Agile и DevOps, CI\CD больше ориентирован на область разработки ПО и не имеет ничего общего с микросервисами;
  • На основе контейнеров или виртуальных машин: Docker, виртуальные машины, физические машины и т. д. являются реализацией физических носителей и не имеют ничего общего с микросервисами;
  • Micro Service Окружающая экология: например, Log Platform, система цепи звонков? Больше - это сила самостоятельной вождения самого R & D для повышения эффективности, и она не зависит от того, как использование использования;
  • Протокол связи. Рекомендуемым протоколом связи для микросервисов является RESTful, а для традиционного SOA — SOAP. Однако существует также множество микросервисов, основанных на легковесных RPC-фреймворках Dubbo, Thrift и gRPC, в Spring Cloud также есть RPC-подобное поведение фреймворка Feign, преобразующего стандартный RESTful в кодовые API, Эти протоколы связи не различают. микросервисная архитектура Основное отличие от SOA-архитектуры;

Конечно, изменения в разработке программного обеспечения (DevOps), инфраструктуре (контейнеризация) и моделях разработки программного обеспечения (гибкая разработка) способствовали популярности микросервисной архитектуры. Микросервисная архитектура — это архитектурный стиль и архитектурная концепция, и «микро» в ней отражает ее суть в сегментации. В реальной реализации микросервисов доказано, что при неправильной сегментации вы не получите обещанных микросервисами преимуществ «низкой связанности, автономности и простоты сопровождения» и будете иметь больше преимуществ, чем монолитная архитектура. Так как его разделить? На самом деле это не какая-то новая методология, а методы проектирования архитектуры, которые предлагались на протяжении многих лет, также называемые основой проектирования микросервисов или моделью архитектуры:Дизайн, управляемый предметной областью, и модель куба.

Дизайн, управляемый доменом

В 2004 году Эрик Эванс опубликовал проект, управляемый доменом (Domain Driven Design, DDD). Дизайн, управляемый предметной областью, существует уже более десяти лет. В книге «Дизайн, управляемый предметной областью», опубликованной Эриком Эвансом, содержится новаторское теоретическое изложение проектирования, ориентированного на предметную область. его закатные годы.. Жаль, что большая часть отечественного технического персонала не разбирается в известной и эффективной методологии проектирования в зарубежных программных кругах, и не применяет ее в проектной практике. Только когда в отрасли дул горячий ветер микросервисов, люди, казалось, заново открыли для себя ценность дизайна, ориентированного на предметную область. его система метода проектирования открыта. , хотя он никогда не был популярен в стране, он сыграл огромную роль. На первый взгляд, именно благодаря микросервисам доменно-ориентированный дизайн снова начал появляться в глазах общественности.

Значение доменно-ориентированного дизайна

Конечно, предметно-ориентированный дизайн — это не «серебряная пуля» или «волшебная пуля», способная решить все неизлечимые болезни. Важность его изучения и применения заключается в следующем:

  • Полный набор методов проектирования программного обеспечения на основе моделей используется для упрощения сложных программных проектов.Он может предоставить вам стандартизированный процесс от стратегического проектирования до тактического проектирования, делая ваши проектные идеи более четкими, а процесс проектирования более стандартизированным;
  • Способ мышления и концепции, которые можно применять к проектам программного обеспечения, связанным со сложным бизнесом, для ускорения реализации проектов;
  • Набор извлеченных принципов и шаблонов может помочь разработчикам разрабатывать элегантные программные системы, способствовать тщательной полировке архитектур и моделей разработчиками, особенно хорошо справляться с эволюционным проектированием системных архитектур, а также помочь улучшить возможности объектно-ориентированного проектирования членов команды и возможности архитектурного проектирования;
  • Архитектура, ориентированная на предметную область, и архитектура микросервисов естественным образом совпадают.Будь то проектирование архитектуры микросервисов в новом проекте или преобразование системы из монолитной архитектуры в проектирование микросервисов, можно следовать архитектурным принципам проектирования, ориентированного на домены.

Конечно, Domain Driven Design может дать нам многое, но если вы попадаете в одну из следующих ситуаций, вам действительно не нужно изучать Domain Driven Design:

  • Если вы самостоятельный архитектор и можете проектировать элегантную программную архитектуру
  • Если вы являетесь эффективным программистом и просто хотите приступить к написанию кода
  • Если вы фронтенд-дизайнер с философией «первый пользовательский опыт»
  • Если программная система, за которую вы отвечаете, несложная, ее могут легко поддерживать два-три человека.

Ключевые понятия DDD

Рождение программной системы должно быть связано с решением проблемы, с которой мы сталкиваемся. Например, компания продавала товары в офлайне, потребляя много финансовых и материальных ресурсов, надеясь продавать свои товары в сети с целью продажи товаров в сети, тогда родилась система электронной коммерции. Часто исходная цель или проблема, которую нужно решить, является отправной точкой программного проекта, указывающей, что мы хотим сделать. Например, интернет-магазин, форум, платежная платформа и т. д.

Далее будет объяснено, как DDD интегрируется в разработку программного обеспечения с точки зрения значения и связи слов «домен», «проблемный домен», «модель предметной области», «дизайн» и «драйвер». Чтобы понять, что такое дизайн, ориентированный на домен, мы должны сначала понять, что такое домен, что такое дизайн, что движет и что движет чем.

Что такое домен / поддомен

Домен — это знания и поведение, связанные с конкретной проблемой. Например, платежная платформа относится к определенному полю. Пока оно находится в этом поле, будут основные связи, такие как учетная запись, учет, сбор, оплата и контроль рисков. Следовательно, системы в одной области все имеют одинаковую основную деятельность, и суть задач, которые они хотят решить, одинакова. Домен можно понимать как проблемный домен, по сути, до тех пор, пока это один и тот же домен, проблемный домен тот же. Поэтому, пока мы определяем поле системы, основной бизнес системы, то есть ключевые проблемы, которые необходимо решить, и границы проблемы в основном определены.

В повседневной разработке мы обычно разбиваем большую программную систему на несколько подсистем. Это разделение может основываться на архитектурных соображениях или на инфраструктуре. В DDD наше разделение систем основано на предметной области (на основе бизнеса). Например, упомянутая выше платежная платформа — это поле, а учетные записи, записи, сборы, платежи и т. д. — подполя. Поле формируется путем объединения многих подполей.

Естественно возникает вопрос:

  • Какие концепции следует моделировать в каких подсистемах?
    • Иногда может оказаться, что моделирование концепции предметной области в подсистеме A вполне приемлемо, а моделирование в подсистеме B — разумно.
  • Как должны быть интегрированы различные подсистемы?
    • Кто-то может сказать, разве это не так просто, как если бы клиент звонил серверу? Проблема в том, что интеграция между двумя системами включает перенос инфраструктуры и различных концепций предметной области между двумя системами, что может испортить нашу хорошо разработанную модель предметной области, если мы не будем осторожны.

В DDD есть стандартные методы решения вышеуказанных проблем, то есть Bounded Context и context map. ** В домене/поддомене мы создаем концептуальную границу домена, где любой объект домена представляет только точное значение, характерное для этой границы. Такие границы называются ограниченными контекстами. Ограниченные контексты и домены имеют отношение один к одному. Физически ограниченный контекст может оказаться файлом Jar/War или даже всеми объектами в пакете. Однако сама технология не используется для разграничения ограниченных контекстов.

Приведенный выше рисунок взят из книги «Реализация дизайна, управляемого предметной областью». Обычно домен имеет одну и только одну основную проблему, которую мы называем «основной домен» домена. При сортировке основного домена, общего поддомена и вспомогательных поддоменов будет определен «ограниченный контекст» и его взаимосвязь в поддомене, и он будет использоваться для объяснения взаимосвязи между поддоменами. Ограниченный контекст можно просто понимать как подсистему или компонентный модуль.

Что такое дизайн

Дизайн в DDD в основном относится к дизайну модели предметной области. DDD — это идея разработки программного обеспечения, основанная на разработке на основе моделей, подчеркивающая, что модель предметной области является ядром всей системы, а модель предметной области также является основной ценностью всей платформы. Каждый домен имеет соответствующую модель предметной области, и модель предметной области вполне может решить ответственные бизнес-задачи. Следовательно, дизайн модели предметной области и дизайн архитектуры одинаково важны.

Что движет

В DDD всегда используются основные проблемы в поле (основные проблемы) в поле. Затем разрабатывается соответствующая модель предметной области, и код проходит через модель предметной области. Дизайн базы данных, методы сохранения не являются ядром DDD, который относится к периферии. В отличие от идеи разработки на основе базы данных, при вождении необходимо помнить два принципа:

  • Проектирование модели предметной области на основе предметной области
  • Реализация кода, управляемого моделью предметной области

Величайшая ценность проектирования, ориентированного на предметную область, заключается в том, что мы можем попрощаться с переходом от процессно-ориентированного мышления (думая о небе, где писать) к системному мышлению, основанному на моделировании. Давайте составим обычный мыслительный процесс в разработке программного обеспечения:

  • 1. Структура таблицы проектирования
  • 2. Написать код (код очень избыточен и недостаточно абстрактен)
  • 3. Поддерживать код (адаптировать к бизнес-изменениям)
  • 4. Возникшие трудности (неразумный дизайн структуры данных, везде избыточный код, модификация BUG и введение новых ошибок, новички читают код и бессловесные книги)
  • 5. Становится все сложнее в обслуживании и начинает рефакторинг (по идее технический долг, измененный на старом фундаменте, сравним с перепланировкой)
  • 6. Завершена реконструкция и запущена новая система (совместимость с историческими данными, миграция данных, параллелизм между старой и новой системами и т.д., но по сути это просто реконструкция кода)
  • 7. Повторите шаги 3-6...

Многоуровневая архитектура DDD

Четырехуровневая архитектура

Эрик Эванс предложил традиционную модель четырехуровневой архитектуры в книге «Domain-Driven Design — How to Cope with Software Core Complexity», а в более позднем процессе эволюции появились пятиуровневая архитектура и шестиуровневая архитектура, как показано на рисунке. на следующем рисунке:

  • Пользовательский интерфейс: уровень пользовательского интерфейса/уровень отображения, отвечающий за взаимодействие с пользователями. Включая отображение информации, интерпретацию пользовательских команд и т. д.;
  • Приложение: прикладной уровень используется для координации взаимодействия между пользователями и приложениями и между приложениями. Не содержит бизнес-логики и не сохраняет состояние бизнес-объектов;
  • Домен: уровень домена/уровень модели, отвечающий за выражение бизнес-концепций, информацию о бизнес-статусе и бизнес-правила. Содержит модель предметной области, информацию о предметной области и состояние бизнес-объектов.Доменный уровень — это ядро ​​программного обеспечения для бизнеса.;
  • Инфраструктура: уровень инфраструктуры предоставляет технические возможности для других уровней. Включая передачу сообщений для прикладного уровня, предоставление механизма сохраняемости для доменного уровня, отрисовку компонентов экрана для уровня пользовательского интерфейса и так далее. Уровень инфраструктуры также может поддерживать режим взаимодействия между четырьмя уровнями через архитектурную структуру.

Шестиугольная архитектура

С последующей эволюцией появился метод улучшения многоуровневой архитектуры, а именно принцип инверсии зависимостей (DIP), предложенный Робертом С. Мартином. Это улучшается за счет изменения зависимостей между различными слоями.

  • Модули высокого уровня не должны зависеть от модулей низкого уровня, оба должны зависеть от абстракций.
  • Абстракция не должна зависеть от деталей, детали должны зависеть от абстракции

Согласно определению этого принципа низкоуровневые компоненты в многоуровневой архитектуре DDD должны зависеть от интерфейсов, предоставляемых высокоуровневыми компонентами, то есть как высокоуровневые, так и низкоуровневые зависят от абстракции. многоуровневая архитектура кажется уплощенной, и к ней добавляется некоторая симметрия, поэтому возникает шестиугольный архитектурный стиль с характеристиками симметрии. Шестиугольная архитектура была предложена Алистером Кокберном в 2005 году. Суть ее состоит в том, чтобы отстаивать то, что разные клиенты взаимодействуют с системой «равным» образом и добиваются каждого конкретного результата путем постоянного расширения адаптеров и преобразования их в параметры, понятные системному API. , и каждый конкретный выход имеет адаптер для выполнения соответствующей функции преобразования.

  • полимеризация:
    • Коллекция связанных объектов со связной связью;
    • – наименьшая атомарная единица, модифицирующая данные;
    • – Доступ к агрегатам обычно осуществляется по идентификатору;
  • Сущность: представляет что-то, что имеет жизненный цикл и будет меняться в течение своего жизненного цикла. Содержит VO, имеет характеристики идентичности, обычно имеет концепцию JPA-тега жизненного цикла.@Entity;
  • Объект значения: представляет описательные и взаимозаменяемые понятия. Подобно pojo, неизменяемый неизменяемый, может передаваться в разных моделях, тег Spring@value;
  • Событие предметной области: кросс-агрегированные изменения всех объектов предметной области должны быть уведомлены и записаны в режиме события, что должно рассматриваться в рамках агрегации соответствующим образом;
  • Фабрика: отвечает за создание и сборку всех объектов;
  • Служба домена: чисто технические службы, такие как ведение журнала или службы оркестрации кросс-агрегации, обычно компонент Spring;
  • Уровень ресурсов (репозиторий): аналогичен уровню DAO, Spring JPA, Hibernate и т. д. @CRUDRepository;
  • Антикоррозийный слой: это не механизм передачи сообщений между системами, его ответственность более специфична для преобразования концептуальных объектов и их поведения в модели или контракте в другую модель или контракт;

Модель анемии против модели перегрузки

После прочтения приведенных выше двух методов многоуровневой архитектуры у многих людей могут возникнуть вопросы, что это такое? Почему я никогда раньше не слышал об этом отделении? Это действительно так.DDD неразрывно связан с объектно-ориентированным, паттернами проектирования и прочими теориями.Если вы не знакомы с OOA и OOD, то DDD может и не понять. Потому что большинство из нас с самого начала нашей карьеры разработчика знакомились с теорией слоев MVC: «уровень действий, уровень обслуживания, уровень дао, уровень БД». И среди 21 шаблона проектирования у нас мало шансов использовать "поведенческий" шаблон проектирования. Причина этих проблем в том, что классический многоуровневый метод разработки J2EE является "анемичной моделью".

Мартин Фаулер (да, тот большой бык, который предложил микросервисы) однажды предложил два метода разработки, а именно:

  • Метод разработки «сценария сделки» на основе «модели анемии»
  • Метод разработки «Dooms», основанный на «модели перегрузки»

Модель анемии

Анемичная модель означает, что объекты используются только для передачи данных между слоями, только поля данных и методы Get/Set, никакой логики в объектах. «Сценарий транзакции» можно понимать как бизнес, организованный с помощью SQL добавления, удаления, изменения и проверки, и это процессно-ориентированное программирование.

Модель перегрузки является сущностью объектно-ориентированного проектирования, объект имеет состояние и поведение. Большая часть бизнес-логики и постоянства размещена в объектах предметной области, а бизнес-логика выполняет только инкапсуляцию, транзакции, разрешения, проверку и другую обработку бизнес-логики.

Например, модуль управления пользователями, вероятно, имеет следующие две реализации:

// 贫血模型下的实现
public class User{
	private Integer id;
	private String name;
	...
	// 省略get/set方法

}

public class UserManager{
	public void save(User user){
		
		// 持久化操作....
	
	}
}

// 保存用户的操作可能是这样
userManager.save(user);


// 充血模型下的实现
public class User{
	private Integer id;
	private String name;
	...
	// 省略get/set方法
	
	public void save(){
	
		// 持久化操作....
	
	}

}

// 保存用户的操作可能是这样
user.save();

«Модель анемии», определенная Мартином Фаулером, является анти-паттерном, и разработать простую небольшую систему со сценариями транзакций не составляет труда; чуть более крупные системы используют сценарии транзакций для увеличения затрат на обслуживание, а бизнес-логика и различные состояния разбросаны по большое количество функций, даже если вы хотите добавить поле в пользовательский объект, это может потребовать настройки нескольких классов...

Есть надежда, что объекты предметной области могут точно выражать бизнес-намерения, но в большинстве случаев мы видим объекты предметной области, полные геттеров и сеттеров. На самом деле, помимо модели анемии и модели гиперемии существуют еще модели кровопотери и модели набухания крови, но последние две в основном не используются в реальных разработках, потому что это две крайности.

Суммировать

В этой статье доменно-ориентированное проектирование представлено с точки зрения макросов. Итак, какова связь между микросервисами и DDD? Фактически, в своей речи в 2015 году Эрик Эванс, автор предложения DDD, выразил свою любовь и поддержку технологии микросервисов и считал, что микросервисы — хороший инструмент для внедрения DDD. Поскольку суть DDD и микросервисов заключается в снижении сложности программных проектов, а DDD — это концепция/метод проектирования, DDD необходимо гарантировать обязательными принципами, иначе в конечном итоге будут смешаны разные объекты предметной области. Некоторые ограничения самих микросервисов, а предпосылку и первичные условия реализации микросервисов может понять каждый, добавят к DDD некоторые принципиальные ограничения с точки зрения реализации. DDD и микросервисы не обязательно использовать одновременно, но если объединить DDD и микросервисы (два метода проектирования программного обеспечения с разницей в десять лет), с этим согласятся два евангелиста Мартин Фаулер и Эрик Эванс.

об авторе

本分类文章，与「随行付研究院」微信号文章同步，第一时间接收公众号推送，请关注「随行付研究院」公众号。

Категории