Домены данных — с чего начать? Стратегия создания data mesh в рамках предприятия
Во всех обсуждениях data mesh, которые я провожу с различными предприятиями, особое внимание уделяется вопросу доменов данных. Клиенты считают, что владение данными, ориентированное на домены, - самая сложная часть работы с data mesh. Зачастую это связано с фундаментальным непониманием принципов проектирования, ориентированного на домены (Domain-Driven Design, DDD). Другие специалисты по работе с данными находят концептуальные понятия DDD слишком сложными для понимания или проецируют примеры, взятые из архитектуры программного обеспечения или объектно-ориентированного программирования, на свою структуру данных. В этой статье я постараюсь дать Вам руководство к действию на понятном человеческом языке, без каких-либо сложных специфических терминов.
Domain-Driven-Design
Начнем с теоретической части: Domain-Driven-Design (DDD) - это метод разработки программного обеспечения, который помогает описывать сложные системы для больших организаций, первоначально описанный Эриком Эвансом. DDD популярен потому, что многие из его практик оказали большое влияние на современные подходы к разработке программного обеспечения и приложений, такие как микросервисы.
DDD оперирует такими понятиями, как ограниченные контексты, домены и субдомены. Домены - это области, в которых объединяются знания, поведение, законы и деятельность. В этих областях можно заметить определенную семантическую связь или поведенческие зависимости между компонентами и сервисами. Домены обычно подразделяются на подобласти. Самым распространенным примером является декомпозиция домена таким образом, чтобы каждая подобласть соответствовала конкретной бизнес-проблеме.
Не все субдомены одинаковы. Например, домены можно разделить на основные, общие или вспомогательные. Основные субдомены - самые важные. Они представляют собой «секретный соус», который делает бизнес уникальным. Общие субдомены неспецифичны и, как правило, легко поддерживаются с помощью готовых продуктов. Вспомогательные субдомены не обеспечивают каких-либо конкурентных преимуществ, но все же необходимы для обеспечения жизнедеятельности организации. Обычно они сравнительно просты.
Ограниченные контексты - это логические (контекстные) границы. Они ориентированы на проектирование систем и приложений. В рамках DDD это может быть код, проектирование баз данных и так далее. Ограниченные контексты, как правило, являются техническими по своей природе и могут охватывать множество доменов и субдоменов.
Сложность применения DDD для управления данными заключается в том, что изначально DDD использовался для моделирования сложных систем в контексте разработки программного обеспечения и не предназначался для моделирования корпоративных данных. Поэтому позвольте мне привести следующую метафору. Представьте себе домен как область общих интересов. Возьмем, к примеру, Ваш дом и улицу. Улица - это домен, где каждый дом представляет собой субдомен. Каждый дом стоит на своем участке и имеет забор, что также подразумевает, что дом не заполняет собой весь участок. Забор - это ограниченный контекст (модель ответственности). Владельцы домов несут ответственность за содержание своих домов и могут делать все, что хотят, но только в пределах своего забора. Однако при пересечении границ (заборов) существуют определенные правила, которых следует придерживаться. Например, выходя из дома или входя в него, всегда необходимо пользоваться общей подъездной дорожкой.
Если рассматривать data mesh как концепцию демократизации данных и реализовать принцип владения данными, ориентированный на домен, то как это будет работать на практике? Как будет выглядеть переход от моделирования корпоративных данных к моделированию проекта, ориентированного на домен? Какие выводы из DDD можно применить к управлению данными?
Проведите декомпозицию Ваших проблемных областей
Моя первая рекомендация - прежде всего, необходимо понять, какие именно проблемы Вы пытаетесь решить. Как утверждают сторонники DDD, установление логических границ между проблемными областями поможет Вам лучше понять ответственность и эффективнее управлять ею.
Чтобы правильно сгруппировать проблемные области, рекомендую Вам внимательно взглянуть на архитектуру бизнеса, в рамках которой существуют определенные бизнес-возможности: способности или умения, которыми предприятие может обладать или обмениваться для достижения определенной цели или результата. Такая абстракция объединяет данные, процессы и технологии в определенном контексте, согласованном со стратегическими бизнес-целями и задачами Вашей организации. Карта бизнес-возможностей показывает, какие функциональные области необходимы для выполнения Вашей миссии.
Карта бизнес-возможностей вымышленной авиакомпании (Автор: Piethein Strengholt)
На рисунке выше Вы можете увидеть декомпозицию деятельности вымышленной авиакомпании Oceanic Airlines, которой для достижения успеха необходимо освоить все функциональные области, перечисленные в Карте бизнес-возможностей. Например, Oceanic Airlines должна уметь продавать билеты в рамках онлайн- или офлайн-систем, а также эффективно управлять занятостью пилотов благодаря программе управления пилотами. Некоторые виды деятельности компания может передать на аутсорсинг, а некоторые - оставить в качестве основного вида своей деятельности.
Со временем Вы увидите, что большинство Ваших сотрудников так или иначе организованы вокруг этих «возможностей». Люди, работающие над одной и той же бизнес-задачей, используют один и тот же словарь. То же самое касается приложений и процессов, которые, как правило, хорошо согласованы и тесно связаны друг с другом. Поэтому создание карты бизнес-возможностей - это отличная отправная точка.
Сопоставление бизнес-возможностей с Вашими приложениями и данными
Для более эффективного управления архитектурой предприятия необходимо согласовать бизнес-возможности, ограниченные контексты и приложения. При этом важно соблюдать некоторые основные правила. Важно, чтобы бизнес-возможности оставались абстрактными. Когда бизнес-возможность внедряется, создается ее реализация - экземпляр возможности - для каждого конкретного контекста. Так, множество приложений и компонентов работают вместе, чтобы обеспечить конкретную ценность для бизнеса.
Приложения и компоненты, связанные с конкретной бизнес-возможностью, остаются отделенными от приложений, связанных с другими бизнес-возможностями. Это обеспечивает большую гибкость, а также позволяет использовать домены и ограниченные контексты, подобно пограничным заборам и домам. Вы можете установить четкие принципы: ограниченные контексты являются производными от бизнес-возможностей и привязаны исключительно к ним. Они представляют собой границу реализации бизнес-возможностей и ведут себя как домен. Если бизнес-возможности меняются, меняются и ограниченные контексты. В идеале хотелось бы добиться полного соответствия между доменами и соответствующими им ограниченными контекстами, но реальность, увы, может быть иной.
Если мы спроецируем отображение возможностей на Oceanic Airlines, то границы ограниченного контекста и реализация домена могут выглядеть следующим образом.
Распределение данных между доменами (автор: Piethein Strengholt)
В примере "Распределение данных между доменами", приведенном выше, управление клиентами основано на экспертизе предметной области и поэтому имеет право определять, какие данные будут передаваться другим доменам. Внутренняя архитектура Управления клиентами является разрозненной, поэтому все компоненты приложений в этих границах могут взаимодействовать напрямую, используя специфические для приложения интерфейсы и модели данных. Однако передача данных в другие домены формализована с помощью продуктов данных и четких стандартов взаимодействия. Это и есть общая подъездная дорога для входа и выхода из Ваших домов! При таком подходе все продукты данных также соответствуют определенному домену и наследуют общепринятый язык - формализованный язык, согласованный между заинтересованными сторонами и разработчиками того же домена, чтобы служить потребностям этого самого домена.
Многократная реализация возможностей приводит к появлению дополнительных доменов
При работе с картой бизнес-возможностей важно понимать, что некоторые бизнес-возможности могут быть реализованы несколько раз. Например, у Oceanic Airlines может быть несколько реализаций "работы с потерянным багажом". Например, одно из направлений бизнеса функционирует только в Азии. В этом контексте "работа с потерянным багажом" - это возможность, которая реализуется для самолетов, связанных с исключительно Азией. Другое направление бизнеса может быть ориентировано на европейский рынок, поэтому в этом контексте используется другая возможность "работы с потерянным багажом". Смысл данной ситуации заключается в том, что связь между бизнес-возможностями и реализациями этих возможностей - один-ко-многим, что также означает, что в итоге Вы получаете дополнительные (суб)домены.
Общие возможности и общие данные
Еще более важным аспектом является то, как следует обращаться с общими бизнес-возможностями. Обычно они реализуются централизованно - в виде сервисной модели - и предоставляются различным бизнес-направлениям. Например, "управление клиентами" может стать такой возможностью. В контексте Oceanic Airlines и азиатское, и европейское направления используют одни и те же принципы управления своими клиентов. Возникает вопрос: как спроектировать владение доменными данными для общей возможности? Вполне вероятно, что несколько представителей бизнеса несут ответственность за клиентов, которые находятся в одной общей области. В заключение следует отметить, что существует домен приложений и домен данных! С точки зрения продукта данных, Ваш домен и ограниченный контекст не совсем совпадают. И наоборот, с точки зрения бизнес-возможностей все еще существует единая проблема данных.
Продукт данных - это единица или компонент архитектуры данных, в котором заключена функциональность для создания оптимизированных для чтения наборов данных, доступных для потребления другими доменами.
Для общих возможностей, таких как решения SaaS и унаследованные системы, я рекомендую придерживаться последовательного подхода к владению данными в домене. Одним из методов может быть разделение прав собственности на данные по продуктам данных, что также может потребовать усовершенствования приложений. В примере с "управлением клиентами" различные конвейеры из домена приложений могут генерировать несколько продуктов данных: один продукт данных для всех клиентов, связанных с Азией, и один - для всех клиентов, связанных с Европой. Это означает, что несколько доменов данных возникают из одного и того же прикладного домена.
Другая техника работы с общими данными заключается в том, чтобы попросить домены приложений разработать единый продукт данных, который содержит метаданные для разграничения прав собственности на данные внутри продукта данных. Например, Вы можете использовать зарезервированное имя столбца для владения, сопоставляя каждую строку с одним конкретным доменом данных. Ниже приведен пример использования столбца домена.
Сложность совместного использования возможностей заключается в том, что домены данных пересекаются с доменами приложений. В идеале команды, владеющие бизнес-возможностями, согласованы с доменами приложений, поэтому право собственности на программное обеспечение и право собственности на данные также согласованы. Если разделение доменов невозможно, необходимо разграничить права собственности на приложения и права собственности на данные. Так, в примере с "управлением клиентами" у Вас будет всего один владелец приложения, который отвечает за базовые технологические сервисы, конвейеры и компоненты приложения. Далее у Вас будет несколько владельцев данных (представителей бизнеса), отвечающих за различные наборы данных, включая регистрацию метаданных, конфиденциальность, безопасность и так далее.
Следите за сложными приложениями, обслуживающими несколько бизнес-функций
Еще один момент, на который следует обратить внимание, - это приложения, обслуживающие сразу несколько бизнес-функций, что часто встречается на крупных предприятиях. Например, компания Oceanic Airlines использует пакет программного обеспечения для "управления затратами" и "активами и финансированием". Такие совместные приложения, как правило, достаточно большие и сравнительно сложные. Домен приложения в такой ситуации будет больше. То же самое относится и к совместному владению, когда в домене приложения находится сразу несколько доменов данных.
Паттерны проектирования для доменов, выровненных по источнику, по потребителю и re-delivery доменов
При составлении карты доменов Вы узнаете, что существуют различные паттерны, основанные на создании, потреблении или повторной доставке данных. Я рекомендую разработать чертежи архитектуры для поддержки Ваших доменов, основываясь на их характеристиках.
Домены, ориентированные на источник, согласованы с системами-источниками, откуда поступают данные. Как правило, это транзакционные или операционные системы. Цель должна состоять в том, чтобы получать данные непосредственно из этих золотых систем-источников. Продукты данных, поступающие из доменов, должны быть оптимизированы для интенсивного потребления данных, поэтому необходимо обеспечить использование стандартизированных сервисов для преобразования и обмена данными в Ваших доменах. Эти службы, включая предварительно сконфигурированные контейнерные структуры, позволяют командам доменов, ориентированным на исходные данные, легче публиковать данные; это путь наименьшего сопротивления, позволяющий сделать правильные вещи с минимальным ущербом и затратами. При правильном проектировании Ваша архитектура будет выглядеть примерно так:
Домены, ориентированные на потребителя, являются противоположностью доменам, ориентированным на источник, поскольку они ориентированы на конкретные сценарии использования конечными пользователями, которым требуются данные из других доменов. Чтобы удовлетворить эти потребности, Вам следует рассмотреть возможность предоставления общих сервисов для преобразования и потребления данных, например возможностей инфраструктуры данных, не зависящих от домена, для работы с конвейерами данных, инфраструктурой хранения, потоковыми сервисами, аналитической обработкой и т.д.
Домены re-delivery: Другой и более сложный процесс - повторное использование данных. Например, несколько потребителей могут быть заинтересованы в комбинации данных из разных областей. Рекомендации по использованию продуктов данных помогут Вам принять правильное решение.
В модели, приведенной ниже, домен владеет как агрегированными данными, пригодными для повторного использования, так и аналитическим сценарием использования. Однако эти две задачи разделены. При таком подходе потребители данных могут безопасно потреблять новые продукты данных, не будучи тесно связанными с аналитическими сценариями использования того же домена. Агрегированные данные в этой ситуации являются входными данными для аналитического сценария использования.
Другим вариантом могут стать вновь созданные данные, которые становятся кандидатами для потребления другими доменами. В этой ситуации потребитель данных становится поставщиком данных и идет по тому же пути распространения данных. Архитектура в этом случае будет выглядеть следующим образом:
Стандартизированные паттерны для решения сложных интеграционных задач
При разбивке корпоративного ландшафта на более мелкие доменные структуры Вы столкнетесь со сложными проблемами интеграции. Если взять пример авиакомпании Oceanic Airways, то данные из "управления клиентами" могут потребоваться в различных других доменах. Или "управление полетов " должно знать, есть ли свободный пилот в "управлении пилотами", прежде чем планировать следующий полет. Как бы Вы решили эту проблему?
Лучшим решением является стандартизация общих паттернов для интеграции междоменных границ. Например, при обработке больших объемов данных можно использовать CQRS для создания хранилищ данных для чтения, ориентированных на домены. Это позволит доменам интенсивно считывать данные из других доменов без необходимости постоянного дублирования данных. Например, для согласованных чтений (и команд) рекомендуется использовать шаблоны API. Следующий обзор с паттернами проектирования может помочь Вам в переходе:
При правильном проектировании общих паттернов управления они также интегрируются с возможностями управления данными. Это позволит Вам собирать метаданные для обеспечения прозрачности и понимания безопасности, наблюдаемости, отслеживания, контроля качества данных и так далее.
Уровень детализации для разделения
Теперь мы знаем, как распознать и упростить домены данных, и переходим к следующему пункту: разработке правильного уровня детализации доменов и правил разделения. При декомпозиции архитектуры важно учесть следующие два важных аспекта:
Во-первых, это детализация функциональных доменов и установление ограниченных контекстов: соответствие методам работы, обеспечение доступности данных для всех доменов и использование общих сервисов, соблюдение стандартов метаданных и так далее. Моя рекомендация по распределению данных заключается в том, чтобы установить как можно более филигранные границы там, где это возможно, потому что ориентироваться на данные - значит сделать данные доступными для их интенсивного (повторного) использования. Если Вы определите границы домена слишком грубо, это приведет к нежелательным связям между многими приложениями, и возможность повторного использования данных будет утрачена. Таким образом, каждый раз, когда данные пересекают границы бизнес-возможностей, важно стремиться к разделению. Это означает, что в пределах одного домена допускается тесное взаимодействие. Однако при пересечении границ домены должны оставаться разобщенными и распространять оптимизированные для чтения продукты данных для обмена данными с другими доменами. Так, например, если подразделениям Oceanic Airlines "Бронирование и комиссии" и "Управление клиентами" необходимо обмениваться данными, они должны использовать общие паттерны «подъездной дороги».
Во-вторых, существует определенная гранулярность для технических доменов и использования инфраструктуры. Представьте себе современную распределенную платформу данных, использующую различные децентрализованные зоны для обеспечения гибкости в обслуживании. Такая зона с общей инфраструктурой и сервисами - как бы Вы предложили это своим командам, работающим в разных доменах? Мой опыт показывает, что многие аспекты, запускающие функциональные домены, будут логически сгруппированы вместе и станут кандидатами на совместное использование инфраструктуры платформы. Вот несколько примеров:
- Согласованность и эффективность методов работы и обмена данными. Это тесно связано с гравитацией данных - тенденцией постоянного обмена большими массивами данных между доменами;
- Региональные границы могут привести к реализации одних и тех же бизнес-возможностей и проектов;
- Разделение доменов может быть вызвано соображениями безопасности, собственности или другими юридическими аспектами. Например, некоторые данные не должны быть доступны другим доменам;
- Важными факторами являются гибкость и темп изменений. В некоторых областях может наблюдаться высокая скорость инноваций, в то время как в других областях очень важна стабильность;
- Функциональные границы могут разделять команды, например, ориентированные на источник/потребителя. Возможно, половина Ваших доменных команд ценит определенные сервисы гораздо больше, чем другие наборы сервисов;
- Причина может заключаться в том, что Вы хотите продать свои возможности, поэтому тесная интеграция с общими службами других доменов будет нецелесообразной;
- Размер, навыки и зрелость команды также могут быть важным фактором. Как правило, высококвалифицированные и зрелые команды стремятся управлять собственными сервисами и инфраструктурой;
- К сожалению, политические границы также могут играть важную роль. Особенно часто это можно наблюдать в том случае, когда бизнес-возможности неправильно согласованы с организационной структурой.
Главное преимущество моделирования бизнес-возможностей заключается в том, что оно помогает лучше распознать и организовать домены в архитектуре data mesh. Оно позволяет получить целостное представление о том, как данные и приложения обеспечивают развитие Вашего бизнеса. В то же время Вы можете определить приоритеты и сфокусироваться на стратегии работы с данными и реальных потребностях бизнеса. Кроме того, Вы можете использовать эту модель не только для работы с данными. Возможно, Вас беспокоит вопрос масштабируемости, тогда Вы можете определить наиболее важные ключевые возможности и разработать стратегию для них.
При объединении всех Ваших доменов и инфраструктурных зон архитектура data mesh должна выглядеть следующим образом:
В модели, приведенной выше, домены организованы логически и эффективно разделяют инфраструктуру, интегрируя и распределяя данные с использованием общих паттернов. Каждая команда по работе с продуктами данных действует как субдомен, принимая на себя ответственность за данные, которые производит и обслуживает. При пересечении границ доменов команды используют общие сервисы данных для преобразования и потребления данных, предлагаемые проектом зоны инфраструктуры.
У некоторых может возникнуть опасение, что построение подобной архитектуры с предварительным составлением схемы - это слишком трудо- и времязатратное занятие. Возможная альтернатива заключается в органичном определении доменов и их включении в архитектуру. Таким образом, вместо того чтобы определять целевое состояние сверху вниз, Вы будете работать снизу вверх: исследовать, экспериментировать и переходить от текущего состояния к целевому. Потенциально такой подход может быть более быстрым, но при этом возникает риск ввязаться в сложные операции по перестройке, когда что-то начнет ломаться. Более осторожным подходом может быть работа в обоих направлениях и достижение середины с течением времени.
Наконец, проектирование распределенной архитектуры в масштабе потребует от Вас масштабного мышления. Моделирование бизнес-возможностей и составление карты ключевых возможностей сгладят декомпозицию доменов.
