Домены данных

Система "Data mesh" основывается на децентрализации и распределении ответственности по доменам. Если вы действительно понимаете часть бизнеса, вы лучше всего можете управлять связанными данными и обеспечить его точность. Это принцип владения доменными данными.

Чтобы обеспечить ориентированное на домен владение данными, необходимо сначала декомпозировать архитектуру данных. Основатель сетки данных, Zhamak Dehghani, способствует подходу Domain-Driven Design (DDD) к разработке программного обеспечения в качестве полезного метода для выявления доменов данных.

Сложность использования DDD для управления данными заключается в том, что исходный вариант использования DDD был моделированием сложных систем в контексте разработки программного обеспечения. Изначально он не был создан для моделирования корпоративных данных, а для практиков по управлению данными его метод может быть абстрактным и техническим. Часто не хватает понимания предметно-ориентированного проектирования (DDD). Специалисты считают концептуальные понятия слишком трудными для понимания или пытаются проецировать примеры из архитектуры программного обеспечения или объектно-ориентированного программирования на свой ландшафт данных. Эта статья содержит прагматическое руководство и четкий словарь, чтобы понять и использовать DDD.

Проектирование на основе домена

Представлен ЭрикОм Эвансом, Domain-Driven Design — это метод поддержки разработки программного обеспечения, который помогает описывать сложные системы для крупных организаций. DDD популярен, так как многие из его высокоуровневых методик влияют на современные подходы к разработке программного обеспечения и приложений, такие как микрослужбы.

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

Домены разложены в поддомены, чтобы лучше управлять сложностью. Типичным примером этого является разложение домена на поддомены, которые соответствуют одной конкретной бизнес-проблеме, как показано в оперативной сетке данных дляИИ/МАШИНного обучения.

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

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

Рекомендации по моделированию домена

Если вы внедряете сетку данных в качестве концепции для демократизации данных и реализуете принцип владения данными, ориентированного на домен, чтобы повысить гибкость, как это работает на практике? Что может выглядеть при переходе от корпоративного моделирования данных к моделированию на основе домена? Какие уроки можно извлечь из DDD для управления данными?

Создание функциональной бизнес-декомпозиции проблемных пространств

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

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

Вы можете просмотреть декомпозицию возможностей вымышленной компании (Tailwind Traders) в следующей модели.

Tailwind Traders необходимо освоить все функциональные области, перечисленные в карте бизнес-возможностей, чтобы добиться успеха. Компания Tailwind Traders должна иметь возможность продавать билеты, как часть онлайн- или оффлайн-систем управления билетами, или иметь пилотов, доступных для полетов самолетов в рамках программы управления пилотами. Компания может передать на аутсорсинг некоторые виды деятельности, сохраняя другие в качестве основной своей деятельности.

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

Сопоставление бизнес-возможностей является отличной отправной точкой, но ваша история не заканчивается здесь.

Сопоставление бизнес-возможностей с приложениями и данными

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

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

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

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

Если мы будем проецировать сопоставление возможностей в контексте Tailwind Traders, границы контекста и реализации домена могут выглядеть, как показано на следующей схеме.

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

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

Дополнительные домены из нескольких реализаций возможностей

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

Например, Tailwind Traders может иметь несколько локализованных внедрений (или воплощений) "обработки багажа и потерянных вещей". Предположим, что одно из их бизнес-направлений работает только в Азии. В этом контексте «обработка багажа и потерянные предметы» — это функция, которая обеспечивается для самолетов, связанных с Азией. Другая линия бизнеса может быть нацелена на европейский рынок, и в этом контексте используется другая функция по обработке багажа и поиску потерянных предметов. Этот сценарий нескольких экземпляров может привести к нескольким локализованным реализациям с помощью разных технологических служб и несвязанных команд для работы с этими службами.

Связь бизнес-возможностей и экземпляров возможностей (реализации) — это один ко многим. В результате этого у вас образуются дополнительные (под-)домены.

Поиск общих возможностей и наблюдение за общими данными

Важно, как вы управляете общими бизнес-возможностями. Обычно вы реализуете общие возможности централизованно, в качестве моделей служб и предоставляете их различным направлениям бизнеса. "Управление клиентами" может быть примером такой возможности. В нашем примере Tailwind Traders как азиатские, так и европейские линии бизнеса используют одно и то же администрирование для своих клиентов.

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

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

Для общих возможностей, таких как сложные пакеты поставщиков, решения SaaS и устаревшие системы, придерживайтесь согласованного подхода к владению данными домена. Вы можете разделить владение данными с помощью продуктов данных, которые могут потребовать улучшения приложений. В нашем примере Tailwind Traders "Управление клиентами" различные конвейеры из домена приложения могут создавать несколько продуктов данных: один продукт данных для всех клиентов, связанных с Азии, и один для всех клиентов, связанных с Европой. В этой ситуации несколько доменов данных происходят из одного домена приложения.

Вы также можете попросить домены приложений создать один продукт данных, который инкапсулирует метаданные для различения владения данными внутри себя. Например, можно зарезервировать имя столбца для владения, сопоставив каждую строку с одним конкретным доменом данных.

Определение монолитов, предлагающих несколько бизнес-возможностей

Обратите внимание также на приложения, которые обращаются к нескольким бизнес-возможностям, которые часто встречаются в крупных и традиционных предприятиях. В нашем примере В нашем примере Tailwind Traders использует сложный пакет программного обеспечения для упрощения как "управления затратами", так и "активов и финансирования". Эти общие приложения — это монолиты, которые обеспечивают максимальное количество функций, что делает их большими и сложными. В такой ситуации домен приложения должен быть больше. То же самое относится к общей собственности, в которой несколько доменов данных находятся в домене приложения.

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

При сопоставлении доменов можно выбрать шаблон на основе создания, потребления или повторной доставки данных. Для архитектуры можно создавать шаблоны, поддерживающие домены на основе конкретных характеристик домена.

Домены, выровненные по исходной системе

Домены, согласованные с исходными системами, соответствуют системам, в которых создаются данные. Обычно эти системы являются транзакциональными или операционными.

Ваша цель состоит в том, чтобы записывать данные непосредственно из этих золотых исходных систем. Оптимизированные для чтения продукты данных из ваших доменов для интенсивного потребления данных. Обеспечивать работу этих доменов с помощью стандартных служб для преобразования данных и совместного использования.

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

Домены, ориентированные на потребителя

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

Рассмотрите возможность предоставления общих служб данных для преобразования и потребления данных для удовлетворения этих потребностей. Можно предложить возможности инфраструктуры данных, не зависящие от домена, например для обработки конвейеров данных, инфраструктуры хранилища, потоковых служб, аналитической обработки и т. д.

Домены повторной доставки

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

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

Определение перекрывающихся шаблонов домена

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

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

• Можно использовать шаблон раздельного подхода, если вы предпочитаете стоимость дублирования вместо повторного использования. Повторное использование приносится в жертву ради большей гибкости и маневренности.
• Шаблон клиент-поставщик можно использовать, если один домен является сильным и готов взять на себя ответственность за данные и нужды нижестоящих потребителей. Недостатки включают несовместимость интересов и вынужденные переговоры, проводимые вашими подчинёнными командами о поставках и приоритетах графиков.
• Шаблон партнерства можно использовать, если логика интеграции координируется незапланированным образом в только что созданном домене. Все команды сотрудничают друг с другом и рассматривают потребности друг друга. Поскольку никто не может свободно изменять общую логику, от всех участников требуется значительное обязательство.
• Шаблон соответствия можно использовать для приведения всех ваших доменов в соответствие со всеми требованиями. Используйте этот шаблон, если работа интеграции сложна, другие стороны не могут контролировать или использовать пакеты поставщиков.

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

Обязанности домена

Data Mesh децентрализует владение данными, распределяя его между командами доменов. Для многих организаций это означает переход от централизованной модели вокруг управления на федеративную модель. Доменные команды назначаются таким задачам, как:

• Взятие на себя ответственности за потоки данных, такие как прием, очистка и преобразование данных, для удовлетворения как можно большего количества потребностей клиентов данных.
• Улучшение качества данных, включая соблюдение соглашений об уровне обслуживания и мерах качества, установленных потребителями данных
• Инкапсуляция метаданных или использование зарезервированных имен столбцов для детализированной фильтрации на уровне строк и столбцов.
• Соблюдение стандартов управления метаданными, в том числе:
  • Регистрация схемы приложений и исходной системы
  • Метаданные для улучшенной возможности обнаружения
  • Информация о версиях
  • Связывание атрибутов данных и бизнес-терминов
  • Целостность метаданных для лучшей интеграции между доменами
• Соблюдение стандартов взаимодействия с данными, включая протоколы, форматы данных и типы данных
• Предоставление происхождения путем связывания исходных систем и служб интеграции с сканерами или путем предоставления происхождения вручную
• Поддержание задач по обмену данными, включая проверки доступа IAM и создание договоров о данных

Уровень детализации для разделения

Теперь, когда вы знаете, как распознать и упростить домены данных, вы можете научиться разрабатывать правильный уровень детализации домена и правила для развязывания. Когда вы разбираете свою архитектуру, в игру вступают два важных аспекта.

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

Задайте точные границы, где это возможно для распределения данных. Управление данными заключается в том, чтобы сделать данные доступными для интенсивного повторного использования. Если вы делаете границы слишком свободными, вы принуждаете к нежелательным связям между многими приложениями и теряете повторное использование данных. Старайтесь разделять данные каждый раз, когда они пересекают границы бизнес-функций. В пределах домена допускается жесткое связывание внутри внутренней архитектуры домена. Однако при пересечении границ бизнес-возможностей домены должны оставаться разделенными и распространять продукты данных, оптимизированные для чтения, для совместного использования с другими доменами.

Гранулярность для технических областей и использования инфраструктуры — другое важное измерение. Зоны приземления данных обеспечивают гибкость для обслуживания приложений данных, создающие продукты данных. Как создать такую зону высадки с общей инфраструктурой и службами, на которые они опираются? Функциональные домены логически группируются и являются хорошими кандидатами для совместного использования инфраструктуры платформы. Ниже приведены некоторые факторы, которые следует учитывать при создании этих целевых зон:

• Согласованность и эффективность при работе с данными и их совместном использовании — это сильный драйвер выравнивания функциональных доменов с зоной приземления данных. Это связано с гравитацией данных, тенденцией постоянно делиться большими продуктами данных между доменами.
• Региональные границы могут вызвать появление дополнительных зон приземления данных.
• Владение, безопасность или юридические границы могут принудительно разделить домены. Например, некоторые данные не могут быть видимы для других доменов.
• Гибкость и темпы изменения являются важными факторами. Некоторые домены могут иметь высокую скорость инноваций, а другие домены сильно ценят стабильность.
• Функциональные границы могут разъединять команды. Примером этого могут быть ориентированные на источник и ориентированные на потребителя границы. Половина ваших доменных команд может ценить определенные службы больше, чем другие.
• Если вы хотите потенциально продавать или отделять свои возможности, следует избегать тесной интеграции с общими службами из других доменов.
• Размер команды, навыки и зрелость могут быть важными факторами. Высококвалифицированные и зрелые команды часто предпочитают управлять своими собственными службами и инфраструктурой, в то время как менее зрелые команды менее склонны ценить дополнительные накладные расходы на обслуживание платформы.

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

Сводка

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

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

Следующий шаг

• Что такое продукт данных?