데이터 도메인

핵심인 데이터 메시의 기본은 도메인에 대한 책임을 분산시키고 분배하는 것입니다. 비즈니스의 이 부분을 진정으로 이해한다면 연결된 데이터를 관리하고 정확성을 보장하는 것이 가장 좋습니다. 이것이 도메인 지향 데이터 소유권의 원칙입니다.

도메인 지향 데이터 소유권을 승격하려면 먼저 데이터 아키텍처를 분해해야 합니다. 데이터 메시의 창설자인 Zhamak Dehghani는 데이터 도메인을 식별하는 데 도움이 되는 유용한 방법으로 소프트웨어 개발에 대한 DDD(Domain-Driven Design) 접근 방식을 홍보합니다.

데이터 관리에 DDD를 사용할 때의 어려움은 DDD의 원래 사용 사례가 소프트웨어 개발 컨텍스트에서 복잡한 시스템의 모델링이었다는 것입니다. 원래 엔터프라이즈 데이터를 모델링하기 위해 만들어지지 않았으며 데이터 관리 실무자의 경우 이 방법은 추상적이고 기술적일 수 있습니다. DDD에 대한 이해가 부족한 경우가 많습니다. 실무자는 개념을 파악하기가 너무 어렵다는 것을 알게 되거나 소프트웨어 아키텍처 또는 개체 지향 프로그래밍의 예제를 데이터 환경으로 프로젝션하려고 합니다. 이 문서에서는 DDD를 이해하고 사용할 수 있도록 실용적인 지침과 명확한 어휘를 제공합니다.

도메인 기반 디자인

Eric Evans가 소개한 도메인 기반 디자인은 대규모 조직을 위한 복잡한 시스템을 설명하는 데 도움이 되는 소프트웨어 개발을 지원하는 방법입니다. DDD는 많은 고급 사례가 마이크로 서비스와 같은 최신 소프트웨어 및 애플리케이션 개발 접근 방식에 영향을 주기 때문에 인기가 있습니다.

DDD는 제한된 컨텍스트, 도메인, 하위 도메인을 구분합니다. 도메인은 해결하려는 문제 공간입니다. 지식, 행동, 법률, 활동이 함께 모이는 영역입니다. 도메인의 의미 체계 결합, 구성 요소 또는 서비스 간의 동작 종속성이 표시됩니다. 도메인의 또 다른 측면은 통신입니다. 팀 구성원은 모든 사람이 효율적으로 작업할 수 있도록 팀 전체가 공유하는 언어를 사용해야 합니다. 이 공유 언어를 유비쿼터스 언어 또는 할기본 언어라고 합니다.

복잡성을 더 잘 관리하기 위해 도메인이 하위 도메인으로 분해됩니다. 이 예제의 일반적인 예는 AI/ML용 Operationalize 데이터 메시에 표시된 것처럼 각각 하나의 특정 비즈니스 문제에 해당하는 do기본 하위 기본 분해하는 것입니다.

모든 하위 도메인이 동일한 것은 아닙니다. 예를 들어 도메인을 핵심, 제네릭 또는 지원으로 분류할 수 있습니다. 핵심 하위 도메인이 가장 중요합니다. 이 도메인은 조직을 고유하게 만드는 비밀 소스이자 재료입니다. 제네릭 하위 도메인은 불특정이고, 일반적으로 기성 제품으로 쉽게 해결할 수 있습니다. 하위 도메인을 지원하는 것은 경쟁 우위를 제공하지 않지만 조직을 계속 운영하는 데 필요하며 일반적으로 복잡하지 않습니다.

제한된 컨텍스트는 논리적(컨텍스트) 경계입니다. 솔루션 공간인 시스템 및 애플리케이션 디자인에 중점을 둡니다. 솔루션 공간에 포커스를 맞추는 것이 적합한 영역입니다. DDD에는 코드, 데이터베이스 디자인 등을 포함할 수 있습니다. 도메인과 제한된 컨텍스트 사이에는 맞춤이 있을 수 있으며, 둘을 함께 바인딩하는 하드 규칙이 없습니다. 제한된 컨텍스트는 기본적으로 기술적이며 여러 도메인 및 하위 도메인에 걸쳐 있습니다.

도메인 모델링 권장 사항

데이터 민주화를 위한 개념으로 데이터 메시를 채택하고 유연성을 높이기 위해 도메인 지향 데이터 소유권 원칙을 구현하는 경우 실제로 어떻게 작동하나요? 엔터프라이즈 데이터 모델링에서 도메인 기반 디자인 모델링으로의 전환은 어떤 모습인가요? 데이터 관리를 위해 DDD에서 수행할 수 있는 단원은 무엇인가요?

문제 공간의 기능적 비즈니스 분해

팀이 데이터를 엔드투엔드를 운영할 수 있도록 허용하기 전에 범위를 살펴보고 해결하려는 문제 공간을 이해합니다. 기술 구현의 세부 정보로 이동하기 전에 먼저 이 연습을 수행하는 것이 중요합니다. 이러한 문제 공간 간에 논리적 경계를 설정하면 책임이 더 명확해지고 더 잘 관리될 수 있습니다.

문제 공간을 그룹화할 때 비즈니스 아키텍처를 살펴봅니다. 비즈니스 아키텍처 내에는 특정 목적 또는 결과를 달성하기 위해 비즈니스가 소유하거나 교환하는 기능과 같은 비즈니스 기능이 있습니다. 이 추상화는 조직의 전략적 비즈니스 목표와 목적에 맞게 데이터, 프로세스, 조직, 기술을 특정 컨텍스트로 압축합니다. 비즈니스 기능 맵은 업무와 비전을 수행하는 데 필요한 기능 영역을 보여 줍니다.

다음 모델에서 가상의 회사인 Tailwind Traders의 기능 분해를 볼 수 있습니다.

Tailwind Traders가 성공하려면 비즈니스 기능 맵에 나열된 모든 기능 영역을 마스터해야 합니다. Tailwind Traders는 예를 들어 온라인 또는 오프라인 티켓 관리 시스템의 일부로 티켓을 판매하거나 파일럿 관리 프로그램의 일환으로 비행기를 조종할 수 있는 파일럿이 있어야 합니다. 회사는 일부 활동을 아웃소싱하면서 다른 활동을 비즈니스의 핵심으로 유지할 수 있습니다.

실제로 관찰할 사항은 대부분의 사람들이 비즈니스 기능을 중심으로 구성되어 있다는 것입니다. 동일한 비즈니스 기능에서 작업하는 사람들은 동일한 어휘를 공유합니다. 지원되는 활동의 응집력에 따라 일반적으로 잘 정렬되고 긴밀하게 연결된 애플리케이션 및 프로세스도 마찬가지입니다.

비즈니스 기능 매핑은 좋은 시작점이지만 여기서는 스토리가 끝나지 않습니다.

애플리케이션 및 데이터에 비즈니스 기능 매핑

엔터프라이즈 아키텍처를 더 잘 관리하려면 비즈니스 기능, 제한된 컨텍스트, 애플리케이션을 조정합니다. 이 작업을 수행할 때는 몇 가지 기초 규칙을 따르는 것이 중요합니다.

비즈니스 기능은 비즈니스 수준에서 유지되어야 하며 추상적으로 유지되어야 합니다. 조직에서 수행하는 작업을 나타내고 문제 공간을 대상으로 지정합니다. 비즈니스 기능을 구현하면 특정 컨텍스트에 대한 실현(기능 인스턴스)이 만들어집니다. 여러 애플리케이션 및 구성 요소가 솔루션 공간의 이러한 경계 내에서 함께 작동하여 특정 비즈니스 가치를 제공합니다.

특정 비즈니스 기능에 맞춰진 애플리케이션 및 구성 요소는 다른 비즈니스 기능에 맞춰진 애플리케이션과 분리된 상태를 유지합니다(다른 비즈니스 문제를 해결하기 때문). 제한된 컨텍스트는 비즈니스 기능에서 파생되고 독점적으로 매핑됩니다. 비즈니스 기능 구현의 경계를 나타내며 도메인처럼 동작합니다.

비즈니스 기능이 변경되면 제한된 컨텍스트가 변경됩니다. 도메인과 제한된 해당 컨텍스트를 전체적으로 맞춰야 하지만, 이후 섹션에서 학습할 때 현실이 이상과 다른 경우가 있습니다.

Tailwind Traders에 기능 매핑을 프로젝션하는 경우 제한된 컨텍스트 경계 및 도메인 구현은 다음 다이어그램과 유사할 수 있습니다.

이 다이어그램에서 고객 관리는 주제별 전문 지식을 기반으로 하므로 다른 도메인에 제공할 데이터를 가장 잘 알고 있습니다. 고객 관리의 내부 아키텍처는 분리되므로 이러한 경계 내의 모든 애플리케이션 구성 요소는 애플리케이션별 인터페이스 및 데이터 모델을 사용하여 직접 통신할 수 있습니다.

데이터 제품 및 명확한 상호 운용성 표준은 다른 도메인에 대한 데이터 배포를 공식화하는 데 사용됩니다. 이 접근 방식에서 모든 데이터 제품은 도메인과 일치하고 동일한 도메인의 이해 관계자 및 디자이너가 동의하여 구성되고 공식화된 언어인 유비쿼터스 언어를 상속하여 해당 도메인의 요구를 충족합니다.

여러 기능 실현의 추가 도메인

비즈니스 기능 맵으로 작업할 때 일부 비즈니스 기능을 여러 번 인스턴스화할 수 있음을 아는 것이 중요합니다.

예를 들어 Tailwind Traders는 “수하물 취급 및 분실물”이라는 여러 지역화된 실현(또는 구현)을 가질 수 있습니다. 비즈니스의 한 라인이 아시아에서만 운영된다고 가정합니다. 이러한 맥락에서 “수하물 취급 및 분실물”은 아시아 관련 항공기에 대해 충족되는 기능입니다. 다른 사업 라인이 유럽 시장을 대상으로 할 수 있으며, 이러한 맥락에서 또 다른 “수하물 취급 및 분실물” 기능이 사용됩니다. 여러 인스턴스로 구성된 이 시나리오는 서로 다른 기술 서비스와 조인되지 않은 팀을 사용하여 여러 지역화된 구현으로 이어져 해당 서비스를 운영할 수 있습니다.

비즈니스 기능 및 기능 인스턴스(실현)의 관계는 일대다입니다. 이 때문에 추가 (하위) 도메인이 생성됩니다.

공유 기능 찾기 및 공유 데이터 주의

공유 비즈니스 기능을 처리하는 방법이 중요합니다. 일반적으로 공유 기능은 중앙에서 서비스 모델로 구현하고 다양한 비즈니스 라인에 제공합니다. “고객 관리”는 이러한 종류의 기능에 대한 예제일 수 있습니다. Tailwind Traders 예제에서 아시아 및 유럽 사업 라인은 모두 클라이언트에 대해 동일한 관리를 사용합니다.

그러나 공유 기능에 도메인 데이터 소유권을 프로젝션하려면 어떻게 해야 하나요? 여러 비즈니스 담당자가 동일한 공유 관리 내에서 고객에 대한 책임을 지게 될 수 있습니다.

애플리케이션 도메인과 데이터 도메인이 있습니다. 도메인 및 제한된 컨텍스트는 데이터 제품 관점에서 완벽하게 맞춰지지 않습니다. 반대로 비즈니스 기능 관점에서 여전히 단일 데이터 문제가 있다고 주장할 수 있습니다.

복잡한 공급업체 패키지, SaaS 솔루션, 레거시 시스템과 같은 공유 기능의 경우 도메인 데이터 소유권 접근 방식에서 일관성을 유지해야 합니다. 애플리케이션 개선이 필요할 수 있는 데이터 제품을 통해 데이터 소유권을 분리할 수 있습니다. Tailwind Traders “고객 관리” 예제에서 애플리케이션 도메인과 다른 파이프라인은 여러 데이터 제품(예: 모든 아시아 관련 고객을 위한 데이터 제품 하나 및 모든 유럽 관련 고객을 위한 제품 하나)을 생성할 수 있습니다. 이 경우 여러 데이터 도메인이 동일한 애플리케이션 도메인에서 시작됩니다.

또한 자체 내에서 데이터 소유권을 구분하기 위해 메타데이터를 캡슐화하는 단일 데이터 제품을 만들도록 애플리케이션 도메인에 요청할 수 있습니다. 예를 들어 소유권의 열 이름을 예약하고 각 행을 단일 특정 데이터 도메인에 매핑할 수 있습니다.

여러 비즈니스 기능을 제공하는 거대한 단일 항목 식별

대기업과 기존 기업에서 흔히 볼 수 있는 여러 비즈니스 기능을 충족하는 애플리케이션에도 주의하세요. 이 예제 시나리오에서 Tailwind Traders는 복잡한 소프트웨어 패키지를 사용하여 “비용 관리”와 “자산 및 금융”을 용이하게 합니다. 이러한 공유 애플리케이션은 가능한 한 많은 기능을 제공하기 때문에 크고 복잡해지는 거대한 단일 애플리케이션입니다. 이러한 상황에서 애플리케이션 도메인은 더 커야 합니다. 하나의 애플리케이션 도메인에 여러 데이터 도메인이 있는 공유 소유권에도 동일하게 적용됩니다.

소스 정렬, 재배포 및 소비자 맞춤 작업에 대한 디자인 패턴기본

할 일기본 매핑할 때 데이터의 생성, 사용 또는 재배포에 따라 패턴을 선택할 수 있습니다. 아키텍처의 경우 do기본 특정 특성에 따라 할 일기본 지원하는 템플릿을 디자인할 수 있습니다.

원본 시스템 맞춤 도메인

원본 시스템 맞춤 도메인은 데이터가 시작되는 원본 시스템과 정렬됩니다. 이러한 시스템은 일반적으로 트랜잭션 또는 운영 시스템입니다.

목표는 이러한 골든 원본 시스템에서 직접 데이터를 캡처하는 것입니다. 데이터 집약적 사용을 위해 제공된 도메인에서 데이터 제품을 읽기 최적화합니다. 데이터 변환 및 공유를 위해 표준화된 서비스를 사용하여 이러한 도메인을 용이하게 합니다.

미리 구성된 컨테이너 구조를 포함하는 이러한 서비스를 사용하면 원본 지향 도메인 팀이 데이터를 보다 쉽게 게시할 수 있습니다. 최소한의 중단과 비용으로 최소한의 저항을 가진 방법입니다.

소비자 맞춤 도메인

소비자 맞춤 도메인은 원본 맞춤 도메인과 반대입니다. 다른 도메인의 데이터가 필요한 특정 최종 사용자 사용 사례와 정렬됩니다. 고객 맞춤 도메인은 조직의 사용 사례에 맞게 데이터를 사용하고 변환합니다.

이러한 소비 요구 사항에 맞게 데이터를 변환하고 사용하도록 공유 데이터 서비스를 제공하는 것이 좋습니다. 예를 들어 데이터 파이프라인, 스토리지 인프라, 스트리밍 서비스, 분석 처리 등을 처리하기 위해 도메인에 구애받지 않은 데이터 인프라 기능을 제공할 수 있습니다.

재배포 도메인

데이터의 재사용 가능성은 특이하고 더 어려운 시나리오입니다. 예를 들어 다운스트림 소비자가 서로 다른 도메인의 데이터 조합에 관심이 있는 경우 데이터를 집계하거나 많은 도메인에 필요한 높은 수준의 데이터를 결합하는 데이터 제품을 만들 수 있습니다. 이를 통해 반복 작업을 방지할 수 있습니다.

데이터 제품과 분석 사용 사례 간에 강력한 종속성을 만들지 마세요. 대신 유연성과 느슨한 결합을 위해 노력하세요. 다음 모델은 유연성을 달성하는 방법을 보여 줍니다. 도메인은 데이터 제품 및 분석 사용 사례 모두에 대한 소유권을 가지며 데이터 제품 생성 및 데이터 사용을 위한 별도의 프로세스를 설계했습니다.

겹치는 도메인 패턴 정의

도메인 모델링은 데이터 또는 비즈니스 논리가 도메인 간에 공유될 때 복잡해지는 경우가 많습니다. 대규모 조직에서 도메인은 종종 다른 도메인의 데이터를 사용합니다. 다른 하위 도메인에서 표준화하고 이점을 얻을 수 있는 방식으로 통합 논리를 제공하는 제네릭 도메인을 사용하는 것이 유용할 수 있습니다. 하위 도메인 간에 공유 모델을 작게 유지하고 항상 유비쿼터스 언어에 맞춥니다.

겹치는 데이터 요구 사항의 경우 도메인 기반 디자인과 다른 패턴을 사용할 수 있습니다. 다음은 선택할 수 있는 패턴에 대한 간단한 요약입니다.

• 재사용 가능성보다 중복 관련 비용을 선호하는 경우 별도의 방법 패턴을 사용할 수 있습니다. 더 높은 유연성과 민첩성을 위해 재사용 가능성이 희생됩니다.
• 한 도메인이 강력하고 다운스트림 소비자의 데이터 및 요구 사항을 소유하려는 경우 고객-공급업체 패턴을 사용할 수 있습니다. 단점으로는 우려 사항 충돌과 다운스트림 팀이 결과물을 협상하고 우선 순위를 예약하도록 강요하는 부분이 있습니다.
• 새로 만든 도메인 내에서 통합 논리가 계획되지 않은 방식으로 조정될 때 파트너 관계 패턴을 사용할 수 있습니다. 모든 팀은 서로의 요구 사항에 협조하고 이를 존중합니다. 공유 논리는 누구도 자유롭게 변경할 수 없으므로 관련된 모든 사람에게 중요한 약속이 필요합니다.
• 순응 패턴을 사용하여 모든 요구 사항에 대한 모든 도메인을 준수할 수 있습니다. 통합 작업이 복잡하거나 다른 당사자가 제어할 수 없거나 공급업체 패키지를 사용하는 경우 이 패턴을 사용합니다.

모든 경우에서 도메인은 상호 운용성 표준을 준수해야 합니다. 다른 도메인에 대한 새 데이터를 생성하는 파트너 관계 도메인은 소유권을 가져오는 것을 포함하여 다른 도메인과 마찬가지로 해당 데이터 제품을 노출해야 합니다.

도메인 책임

데이터 메시는 도메인 팀 간에 배포하여 데이터 소유권을 분산시킵니다. 이는 많은 조직에서 거버넌스와 관련한 중앙 집중식 모델에서 페더레이션된 모델로의 전환을 의미합니다. 도메인 팀에는 다음과 같은 작업이 할당됩니다.

• 수집, 정리, 변환과 같은 데이터 파이프라인의 소유권을 가져와서 가능한 한 많은 데이터 고객의 요구 사항을 충족합니다.
• SLA 준수 및 데이터 소비자가 설정한 품질 측정값을 포함하여 데이터 품질 개선
• 세부적인 행과 열 수준 필터링을 위해 메타데이터 캡슐화 또는 예약 열 이름 사용
• 다음을 비롯한 메타데이터 관리 표준을 준수합니다.
  • 애플리케이션 및 원본 시스템 스키마 등록
  • 향상된 검색 가능성을 위한 메타데이터
  • 버전 관리 정보
  • 데이터 특성 및 비즈니스 용어의 연결
  • 도메인 간의 통합을 개선하기 위한 메타데이터 정보의 무결성
• 프로토콜, 데이터 형식, 데이터 형식을 비롯한 데이터 상호 운용성 표준 준수
• 원본 시스템과 통합 서비스를 스캐너에 연결하거나 계보를 수동으로 제공하여 계보 제공
• IAM 액세스 검토 및 데이터 계약 만들기를 비롯한 데이터 공유 작업 준수

분리 세분성 수준

이제 데이터 도메인을 인식하고 용이하게 하는 방법을 알아보고 적절한 수준의 도메인 세분성 및 분리 규칙을 디자인하는 방법을 배울 수 있습니다. 아키텍처를 분해할 때는 두 가지 중요한 차원이 작용합니다.

기능 도메인에 대한 세분성 및 제한된 컨텍스트 설정은 1차원입니다. 도메인은 특정 작업 방식을 준수함으로써 공유 서비스, 소유권 가져오기, 메타데이터 표준 준수 등을 사용하여 모든 도메인에서 데이터를 사용할 수 있도록 합니다.

데이터 배포를 위해 가능한 경우 세분화된 경계를 설정합니다. 데이터 중심이 되는 것은 데이터를 집중적으로 재사용할 수 있도록 하는 것입니다. 경계를 너무 느슨하게 만드는 경우 많은 애플리케이션 간에 원치 않는 결합을 강제로 적용하고 데이터 재사용 가능성을 잃게 됩니다. 데이터가 비즈니스 기능의 경계를 넘을 때마다 분리하기 위해 노력합니다. 도메인의 도메인 내부 아키텍처 내에서 긴밀한 결합이 허용됩니다. 그러나 비즈니스 기능의 경계를 넘을 경우 도메인은 분리된 상태를 유지하고 다른 도메인과 공유하기 위해 읽기 최적화 데이터 제품을 배포해야 합니다.

기술 도메인 및 인프라 사용률에 대한 세분성은 다른 중요한 차원입니다. 데이터 랜딩 존은 데이터 제품을 만드는 데이터 애플리케이션을 서비스하기 위한 민첩성을 지원합니다. 공유 인프라 및 서비스를 사용하여 이러한 종류의 랜딩 존을 만들려면 어떻게 해야 하나요? 기능 도메인은 논리적으로 함께 그룹화되며 플랫폼 인프라를 공유하기에 적합한 후보입니다. 이러한 랜딩 존을 만들 때 고려해야 할 몇 가지 요소는 다음과 같습니다.

• 데이터로 작업하고 공유할 때의 응집력과 효율성은 기능 도메인을 데이터 랜딩 존에 맞추는 강력한 동인입니다. 이는 대용량 데이터 제품을 도메인 간에 지속적으로 공유하는 경향이 있는 데이터 중력과 관련이 있습니다.
• 지역 경계로 인해 추가 데이터 랜딩 존이 구현될 수 있습니다.
• 소유권, 보안 또는 법적 경계는 도메인을 강제로 분리할 수 있습니다. 예를 들어 일부 데이터는 다른 도메인에 표시될 수 없습니다.
• 유연성과 변화 속도는 중요한 동인입니다. 일부 도메인은 높은 수준의 혁신을 이룰 수 있지만 또 다른 도메인은 안정성을 매우 중시합니다.
• 기능적 경계는 팀을 분리시킬 수 있습니다. 이러한 예는 원본 지향 및 소비자 지향 경계일 수 있습니다. 도메인 팀의 절반은 다른 팀보다 특정 서비스를 중시할 수 있습니다.
• 잠재적으로 기능을 판매하거나 분리하려는 경우 다른 도메인의 공유 서비스와 긴밀하게 통합하지 않아야 합니다.
• 팀 크기, 기술, 성숙도는 모두 중요한 요소가 될 수 있습니다. 고도로 숙련되고 성숙한 팀은 종종 자체 서비스 및 인프라를 운영하는 것을 선호하지만, 덜 성숙한 팀은 플랫폼 유지 관리의 추가 오버헤드를 평가하지 않을 것입니다.

많은 데이터 랜딩 존을 프로비전하기 전에 도메인 분해를 살펴보고 기본 인프라를 공유할 기능 도메인을 결정합니다.

요약

비즈니스 기능 모델링을 사용하면 데이터 메시 아키텍처에서 도메인을 더 잘 인식하고 구성할 수 있습니다. 데이터 및 애플리케이션이 비즈니스에 가치를 제공하는 방식을 전체적으로 보여 주는 동시에 데이터 전략 및 비즈니스 요구 사항에 우선 순위를 지정하고 집중하는 데 도움이 됩니다. 데이터가 아닌 다른 항목에 비즈니스 기능 모델링을 사용할 수도 있습니다. 예를 들어 확장성이 중요한 경우 이 모델을 사용하여 가장 중요한 핵심 기능을 식별하고 전략을 개발할 수 있습니다.

일부 실무자들은 모든 것을 미리 매핑하여 대상 상태 아키텍처를 구축하는 것이 많은 주의를 기울여 하는 작업이라는 우려를 제기합니다. 대신 새 데이터 메시 아키텍처에 등록하는 동안 도메인을 유기적으로 식별하는 것이 좋습니다. 위에서 아래로 대상 상태를 정의하는 대신 상향식으로 작업하고, 탐색하고, 실험하고, 현재 상태를 대상 상태로 전환합니다. 이 제안된 접근 방식은 더 빠를 수 있지만 상당한 위험을 수반합니다. 작업이 중단되기 시작했을 때는 분명 복잡한 움직임 또는 리모델링 작업 중일 수 있습니다. 양방향, 하향식, 상향식으로 작업한 다음, 시간이 지남에 따라 중간에 만나는 것이 더 미묘한 접근 방식입니다.

다음 단계

• 데이터 제품이란?