Предметные области

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домены Redelivery

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

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