DDD простыми словами
Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.
Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере.
Симптомы:
Между командами происходит борьба на чьей стороне должен быть разработан новый функционал
Каждая команда считает, что на её стороне, либо же наоборот, хочет сбросить с себя новый функционал и перекинуть его на другую команду
Происходит это чаще всего из-за того, что границы систем размыты и нет чёткого понимания, что должно входить в систему, а что нет.
Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.
По сути, речь идёт о том, что системы становится слишком большими и для их доработки требуется длительный процесс погружения.
Можно ли исправить ситуацию коренным образом?
Простое решение для сложной проблемы
Для начала вспомним проблемы:
Системы большие по размеру — они жрут много ресурсов и сложны в сопровождении
Системы сложные и в них трудно разобраться, поэтому существуют специализированные команды по разработке конкретных систем
Нет четких границ систем, поэтому между командами возникают битвы за функционал
Теперь давайте представим обратную ситуацию:
Системы маленькие по размеру — в них легко разобраться и дорабатывать
Системы очень простые и разобраться в них элементарно — специализированные команды становятся не нужны
Есть кристально чёткие границы систем — битвы между командами за функционал уходят в историю
Возможно ли такое вообще?
Большинство скажет, что нет, невозможно. Но некоторые все же ответят: да, возможно, и будут правы.
Если освободиться от устаревших установок и неработающих политик, то становится очевидно, что сделать систему, состоящую из простых и несложных компонент все же можно.
Есть такой подход — DDD (Domain Driven Design), который как раз и предлагает способ построение больших систем на основе супер-простых элементарных компонент.
DDD — это микросервисная архитектура на базе сущностей предметной области.
Атомами системы выступают малюсенькие микросервисы, соответствующие элементарным понятиям бизнесовой предметной области.
Специально для этих целей вводится понятие «Единого языка» (Ubiquitous language).
Единый язык в этом контексте обозначает, что Микросервис = Сущность предметной области, и не более.
Т.е. это обозначает, что бизнес и разработка всегда будут «говорить» про одно и то же. Если бизнес говорит «Заказ», то разработка понимает, что речь идёт о микросервисе «Заказ». Если бизнес говорит «Корзина», то разработка понимает, что речь идёт о микросервисе «Корзина». Если бизнес говорит «Поставка», то речь о микросервисе «Поставка».
Фактически говорится, что микросервисы создаются четко под бизнес-сущности, а не каким-то другим специфическим образом.
Понятие «Система» в корпоративном понимании монструозного приложения уходит в прошлое, а на её место приходят десятки мелких бизнес-ориентированных равнозначных одноуровневых микросервисов.
Понятные чёткие границы
С чего начинается любая разработка? С того, что бизнес пытается объяснить разработчикам чего он хочет.
Например, приходит бизнес и говорит: я хочу сократить время вывода новых продуктов на рынок.
Конечно, Вы сразу же просите пояснить, что он под этим имеет ввиду?
Бизнес начинает описывать процесс: «Хочу, чтобы поставщик самостоятельно заводил описание новой товарной номенклатуры, а затем загружал её к нам. После проверки и полной загрузки номенклатура должна одномоментно появится во всех каналах продаж (офисы продаж, интернет-магазин, мобильное приложение)»
В самой формулировке бизнеса содержится ответ на вопрос о границах.
В бизнес-описании фигурируют следующие сущности предметной области:
Т.к. сущности предметной области являются микросервисами, то сразу же очевидно какие микросервисы будут меняться — «Товарная номенклатура» и «Канал продаж».
Также сразу можно выделить и операции с этими микросервисами, которые необходимо реализовать в рамках доработки.
Операции с товарной номенклатурой (взятые из бизнес-описания) могут быть, например, такими (выделены жирным шрифтом в бизнес-описании):
Создать
Загрузить
Проверить
Показать
Свойства номенклатуры:
Описание
Статус показа номенклатуры в каналах продаж (показывается/не показывается)
Статус полноты загрузки (полностью/не полностью)
Бизнес-правила:
Номенклатура может быть показана только при её полной загрузке и проверке
Номенклатура может быть загружена только пакетом
Как-то так.
Мелкие микросервисы
Действительно ли в результате получаются мелкие микросервисы? Чтобы это понять, давайте взглянем для начала на микросервис «Канал продаж».
Какие свойства канала продаж Вам приходят в голову исходя из бизнес-описания?
Да кроме названия канала там больше ничего и нет. Т.е. весь микросервис будет состоять из одной таблицы с двумя полями — первичным ключом и названием.
Теперь посмотрим на вариант посложнее: что будет представлять из себя микросервис «Номенклатура»?
Очевидно, что там будет таблица с номенклатурными позициями, а также таблица с загруженными пакетами и результатами их проверки. Т.е. порядка 3–5 таблиц.
Легко разобраться и понять
Небольшой размер микросервисов в сочетании с простой внутренней архитектурой (например, «луковой») даёт феноменальный результат, когда сделать правки в микросервис может, в буквальном смысле, даже неподготовленный разработчик.
«Луковая» архитектура, когда применяется одинаково ко всем микросервисам сразу, позволяет сходу понять куда именно в микросервисе встроится, чтобы корректно сделать правки.
Суть архитектуры в том, что в ней выделяются чёткие слои: входные и выходные адаптеры, уровень сервисов приложения, уровни доменной модели и инфраструктуры.
Любой разработчик, если понимает суть луковой архитектуры, быстро найдет где именно и что ему надо встроить.
Результат — децентрализация команд, возможность подключения команд к разработке любого микросервиса в компании, ненужность специализации на одной системе.
Выводы
Если отбросить шелуху и красивые иностранные слова наподобие «Bounded context», «Event storming» и проч., которые только путают, то в остатке остается весьма красивая, простая и доступная для понимания концепция корпоративной микросервисной архитектуры.
Основные преимущества концепции DDD:
Единый язык с бизнесом
Кристально чёткие границы микросервисов
Простая внутренняя структура
Легкость понимания неподготовленным разработчиком
Относительно небольшое число микросервисов даже в больших корпорациях
Конечно, как и любой другой архитектурный подход, она требует понимания и анализа применимости в каждой конкретной ситуации.
Пользуйтесь, получайте выгоду и упрощайте себе жизнь.
Оставьте свой комментарий — выскажите своё мнение о концепции и о статье.
