數據域

以數據網格為核心，以分散方式建立，並將責任散發給網域。 如果您真正瞭解此部分的業務，最好能夠管理相關聯的數據，並確保其正確性。 這是網域導向數據擁有權的原則。

若要提升網域導向的數據擁有權，您必須先分解數據架構。 數據網格創始人 Zhamak Dehghani 會將網域驅動設計 （DDD） 方法提升為軟體開發的實用方法，以協助您識別數據網域。

使用 DDD 進行數據管理的困難在於，DDD 的原始使用案例是在軟體開發內容中將複雜的系統模型化。 它最初不是為了建立企業數據模型，而且對於數據管理從業者來說，其方法可以是抽象和技術。 通常也缺乏對 DDD 的理解。 從業者發現其概念過於難以把握，或嘗試將軟體架構或面向對象程序設計中的範例投影到其數據環境。 本文提供務實的指引和清楚的詞彙，讓您瞭解和使用 DDD。

網域導向設計

由 Eric Evans 引進，Domain-Driven Design 是支援軟體開發的方法，可協助描述大型組織的複雜系統。 DDD 很受歡迎，因為其許多高階做法會影響微服務等專案的新式軟體和應用程式開發方法。

DDD 區分界限內容、網域和子域。 網域是您想要解決的問題空間。 它們是知識、行為、法律和活動聚集在一起的領域。 您會看到網域中的語意結合、元件或服務之間的行為相依性。 網域的另一個層面是通訊。 小組成員必須使用整個小組共用的語言，讓每個人都能有效率地工作。 此共用語言稱為 無處不在的語言 或 領域語言。

網域會分解成子域，以更妥善地管理複雜度。 其中常見的範例是將網域分解成子域，每個網域都對應至一個特定的商務問題，如AI/ML 的數據網格運作所示。

並非所有子域都相同。 例如，您可以將網域分類為核心、泛型或支援。 核心子域是最重要的。 他們是使組織與眾不同的秘密醬汁，成分。 泛型子域是非特定，通常很容易使用現成的產品來解決。 支援子域不提供競爭優勢，但必須讓組織保持運作，而且通常並不複雜。

限定內容是邏輯（內容）界限。 它們著重於解決方案空間：系統與應用程式的設計。 這是一個區域，焦點在解決方案空間上的對齊是合理的。 在 DDD 內，這可以包含程式代碼、資料庫設計等等。 在定義域與限定內容之間，可以對齊，沒有硬式規則會將兩者系結在一起。 限定的內容本質上是技術性的，而且可以跨越多個網域和子域。

領域模型化建議

如果您採用數據網格作為數據大眾化的概念，並實作面向領域數據擁有權的原則，以提高彈性，則此做法如何運作？ 從企業數據模型轉換為領域驅動設計模型的外觀為何？ 您可以從 DDD 取得哪些課程以進行資料管理？

使問題空間的功能商務分解

在允許小組端對端操作其數據之前，請先查看範圍並瞭解您嘗試解決的問題空間。 請務必先執行此練習，再跳到技術實作的詳細數據。 當您設定這些問題空間之間的邏輯界限時，責任會變得更清楚，而且可以更妥善地管理。

將問題空間分組時，請查看您的商務架構。 在商務架構中，有商務功能：企業擁有或交換的能力或容量，以達成特定用途或結果。 此抽象概念會將數據、程式、組織和技術納入特定內容，以配合您組織的策略性商務目標和目標。 商務功能地圖會顯示哪些功能區域似乎必須符合您的任務和願景。

您可以在下列模型中檢視虛構公司 Tailwind Traders 的功能分解。

Tailwind Traders 必須掌握商務功能對應中列出的所有功能區域才能成功。 Tailwind Traders 必須能夠在在線或離線票證管理系統中銷售票證，例如，或讓飛行員可在飛行員管理計劃中飛行飛機。 公司可以外包某些活動，同時將其他活動作為其業務的核心。

您實際上會觀察到的是，大部分的人都是圍繞商務功能進行組織。 人員 使用相同的商務功能共用相同的詞彙。 您的應用程式和程式也是如此，這些應用程式與程式通常會根據所支援活動的凝聚力，正確對齊且緊密連接。

商務功能對應是一個絕佳的起點，但您的故事不會在此結束。

將商務功能對應至應用程式和數據

若要更妥善地管理您的企業架構，請讓商務功能、限定內容和應用程式保持一致。 請務必遵循一些基礎規則，就像你這樣做一樣。

商務功能必須維持在商務層級，並保持抽象。 它們代表貴組織所做的工作，並以您的問題空間為目標。 當您實作商務功能時，會建立特定內容的實現（功能實例）。 多個應用程式和元件可在解決方案空間的這類界限內共同運作，以提供特定的商業價值。

與特定商務功能一致的應用程式和元件會保持與與其他商務功能一致的應用程式分離，因為它們解決了不同的商務考慮。 系結內容衍生自 並專門對應至商務功能。 它們代表商務功能實作的界限，其行為就像網域一樣。

如果商務功能變更，限定內容就會變更。 您最好預期定義域與對應的限定內容之間完全一致，但當您在稍後的章節中瞭解時，現實有時會與理想不同。

如果我們將功能對應至Tailwind Traders，限定的內容界限和網域實作看起來可能會類似下圖。

在此圖表中，客戶管理是以主題專業知識為基礎，因此最瞭解哪些數據要用於其他網域。 客戶管理的內部架構已分離，因此這些界限內的所有應用程式元件都可以使用應用程式特定的介面和數據模型直接通訊。

數據產品和 清楚的互操作性標準可用來將數據散發正規化至其他網域。 在這個方法中，所有數據產品也會與定義域一致，並繼承無處不在的語言，這是一種建構、正規化的語言，由同一個網域的項目關係人和設計師所同意，以滿足該定義域的需求。

多個功能實現的額外網域

使用商務功能對應時，請務必確認某些商務功能可以具現化多次。

例如，Tailwind Traders 可能會有多個當地語系化的實現（或實作）「行李處理和遺失專案」。 假設其中一家企業只在亞洲運營。 在此背景下，「行李處理和丟失物品」是亞洲相關飛機的一項功能。 不同的企業營運可能會針對歐洲市場，在此背景下，會使用另一種「行李處理和遺失物品」功能。 此案例有多個實例可能會導致使用不同技術服務和脫離小組來操作這些服務的多個當地語系化實作。

商務功能和功能實例（實現）的關係是一對多。 因此，您最終會擁有額外的 （子） 網域。

尋找共用功能並注意共享數據

處理共用商務功能的方式很重要。 您通常會以服務模型的形式集中實作共用功能，並將其提供給不同的企業營運。 「客戶管理」可以是這類功能的範例。 在我們的 Tailwind Traders 範例中，亞洲和歐洲企業營運都會為其客戶使用相同的系統管理。

但是，如何在共用功能上投影網域數據擁有權？ 多個商務代表可能會對相同共用管理內的客戶負責。

有一個應用程式域和數據域。 您的網域和限定內容無法從數據產品觀點完全對齊。 相反地，您可能會爭辯說，從商務能力的觀點來看，仍有單一數據關注。

針對複雜的廠商套件、SaaS 解決方案和舊版系統等共用功能，在網域數據擁有權方法中保持一致。 您可以透過數據產品來隔離數據擁有權，這可能需要應用程式改進。 在我們的 Tailwind Traders「客戶管理」範例中，應用程式域的不同管線可能會產生多個數據產品：所有亞洲相關客戶的一個數據產品，以及所有歐洲相關客戶的一個數據產品。 在此情況下，多個數據域源自相同的應用程式域。

您也可以要求應用程式域建立單一數據產品，以封裝元數據，以區分本身的數據擁有權。 例如，您可以保留擁有權的數據行名稱，將每個數據列對應至單一特定數據域。

識別提供多個商務功能的整合型

也請注意滿足多種商務功能的應用程式，這些功能經常出現在大型企業和傳統企業中。 在我們的範例案例中，Tailwind Traders使用複雜的軟體套件來協助「成本管理」和「資產和融資」。 這些共用應用程式是一體型，可提供盡可能多的功能，使其變得龐大且複雜。 在這種情況下，應用程式域應該更大。 同樣的事情適用於共用擁有權，其中數個數據域位於應用程式域中。

來源對齊、重新傳遞和取用者對齊網域的設計模式

當您對應網域時，您可以根據資料的建立、耗用量或重新傳遞來選擇模式。 針對您的架構，您可以根據網域的特定特性來設計支援網域的範本。

來源系統對齊的網域

來源系統對齊的網域會與數據來源系統一致。 這些系統通常是交易式或可操作的。

您的目標是直接從這些黃金來源系統擷取數據。 從您提供的網域讀取優化數據產品，以耗用大量數據。 使用標準化服務進行數據轉換和共用，協助這些網域。

這些服務包含預先設定的容器結構，可讓您的來源導向網域小組更輕鬆地發佈數據。 這是最少阻力的路徑，最少的中斷和成本。

取用者對齊的網域

取用者對齊的網域與來源對齊網域相反。 它們與需要其他網域數據的特定使用者使用案例一致。 客戶對齊的網域會取用和轉換數據，以符合貴組織的使用案例。

請考慮提供共用數據服務來進行數據轉換和取用，以滿足這些取用需求。 例如，您可以提供與網域無關的數據基礎結構功能，以處理數據管線、記憶體基礎結構、串流服務、分析處理等等。

Redelivery 網域

數據的重複使用性是不同且更困難的案例。 例如，如果下游取用者對來自不同網域的數據組合感興趣，您可以建立匯總數據的數據產品，或結合許多網域所需的高階數據。 這可讓您避免重複的工作。

請勿在數據產品與分析使用案例之間建立強相依性。 請改用彈性和鬆散結合。 下列模型示範如何達成彈性。 定義域會同時取得數據產品和服務分析使用案例的擁有權，並針對數據產品建立和數據使用量設計了個別的程式。

定義重疊的網域模式

當跨定義域共用數據或商業規則時，定義域模型化通常會變得複雜。 在大型組織中，網域通常會依賴來自其他網域的數據。 讓泛型定義域以允許其他子域標準化並從中受益的方式，提供整合邏輯會很有説明。 將子域之間的共用模型保持為小，且一律與無處不在的語言一致。

針對重疊的數據需求，您可以使用與網域驅動設計不同的模式。 以下是您可以選擇的模式簡短摘要：

• 如果您偏好複製的相關成本，而不是重複使用性，則可以使用個別方式模式。 可重複使用性因更高的彈性和靈活性而犧牲。
• 如果某個網域強大且願意擁有下游取用者數據和需求的擁有權，則可以使用客戶供應商模式。 缺點包括衝突的考慮，並迫使下游小組交涉交付專案和排程優先順序。
• 當您的整合邏輯在新建立的網域內以非計劃的方式協調時，可以使用合作關係模式。 所有團隊都合作，並考慮彼此的需求。 因為沒有人可以自由變更共享邏輯，因此每個相關人員都需要做出重大承諾。
• 一致性模式可用來將所有網域都符合所有需求。 當您的整合工作很複雜、沒有其他合作物件可以控制，或使用廠商套件時，請使用此模式。

在所有情況下，您的網域都應該遵守您的互操作性標準。 為其他網域產生新數據的合作關係網域，必須像任何其他網域一樣公開其數據產品，包括取得擁有權。

網域責任

數據網格會在網域小組之間散發數據擁有權，以分散數據擁有權。 對於許多組織來說，這表示從治理的集中式模型轉移到同盟模型。 網域小組會指派工作，例如：

• 取得數據管線的擁有權，例如擷取、清理和轉換數據，以盡可能滿足客戶的需求
• 改善 數據品質，包括遵守數據取用者所設定的SLA和品質量值
• 封裝元數據或使用保留的數據行名稱進行精細的數據列和數據行層級篩選
• 遵守元數據管理標準，包括：
  • 應用程式和來源系統架構註冊
  • 改善可探索性的元數據
  • 版本控制資訊
  • 數據屬性和商務詞彙連結
  • 元數據資訊的完整性，以允許網域之間更好的整合
• 遵守數據互操作性標準，包括通訊協定、數據格式和數據類型
• 藉由將來源系統和整合服務鏈接至掃描器，或手動提供譜系來提供譜系
• 遵守數據共用工作，包括IAM存取權檢閱和數據合約建立

分離的數據粒度層級

現在您已瞭解如何辨識及促進數據域，您可以瞭解如何設計正確的網域粒度層級和分離規則。 當您分解架構時，有兩個重要維度正在作用中。

功能域和設定限定內容的數據粒度是一個維度。 網域符合特定運作方式，確保數據可供所有使用共用服務、取得擁有權、遵守元數據標準等網域使用。

盡可能設定數據散發的細微界限。 成為數據驅動就是讓數據可供大量重複使用。 如果您讓界限過於鬆散，則會強制許多應用程式之間的不想要結合，並失去數據重複使用性。 爭取在每次數據跨越商務功能的界限時分離。 在網域內，允許在網域的內部架構內緊密結合。 不過，當跨越商務功能的界限時，網域必須保持分離，並散發讀取優化的數據產品，以便與其他網域共用。

技術網域和基礎結構使用率的粒度是另一個重要維度。 您的資料 登陸區域 可讓您靈活維護 數據應用程式，以建立數據產品。 如何建立這種登陸區域，其中包含下方的共用基礎結構和服務？ 功能網域會以邏輯方式分組在一起，而且是共用平臺基礎結構的良好候選專案。 以下是建立這些登陸區域時需要考慮的一些因素：

• 使用和共享數據時的凝聚力和效率是將功能網域與數據登陸區域對齊的強大驅動程式。 這與數據重力有關，這種趨勢會持續共用網域之間的大型數據產品。
• 區域界限可能會導致額外的數據登陸區域正在實作。
• 擁有權、安全性或法律界限可以強制網域隔離。 例如，其他任何網域都看不到某些數據。
• 彈性和變革速度是重要的驅動因素。 某些領域可以有很高的創新速度，而其他領域則高度重視穩定性。
• 功能界限可以將團隊分開。 其中一個範例可能是來源導向和取用者導向的界限。 您的一半網域小組可能會對其他小組重視某些服務。
• 如果您想要可能出售或區隔您的功能，您應該避免與來自其他網域的共用服務緊密整合。
• 團隊大小、技能和成熟度都可以是重要的因素。 高技能且成熟的小組通常會偏好自行操作服務和基礎結構，而較不成熟的小組則較不重視平臺維護的額外負荷。

布建許多數據登陸區域之前，請先查看網域分解，並判斷哪些功能網域是共用基礎結構的候選專案。

摘要

商務功能模型化可協助您在數據網格架構中更清楚地辨識及組織您的網域。 它提供數據與應用程式將價值傳遞給您企業的方式的整體檢視，同時協助您排定優先順序並專注於數據策略和商務需求。 您也可以對不僅僅是數據使用商務功能模型化。 例如，如果延展性是問題，您可以使用此模型來識別您最重要的核心功能，併為其開發策略。

一些從業者擔心，透過預先對應所有專案來建立目標狀態架構是一個密集的練習。 相反地，建議您在將網域上線到新的數據網格架構時，以有機方式識別您的網域。 您不必從上而下定義目標狀態，而是從下到下、探索、實驗和將目前狀態轉換為目標狀態。 雖然這個建議的方法可能更快，但它具有重大風險。 當事情開始中斷時，您可以輕鬆地在複雜的移動或重建作業中間。 從兩個方向，從上到下和從下到下工作，然後一段時間在中間開會是一個更細微的方法。

後續步驟

• 什麼是數據產品？