數據域
數據網格基本上是以分散化和將責任分配給不同網域為基本原則。 如果您真正了解企業的一部分，最好能夠管理相關聯的數據，並確保其正確性。 這是網域導向數據擁有權的原則。
若要提升網域導向的數據擁有權，您必須先分解數據架構。 數據網格創始人 Zhamak Dehghani 推廣 Domain-Driven 設計（DDD）方法作為軟體開發中的一種實用方法，幫助您識別數據領域。
使用 DDD 進行數據管理的困難在於，DDD 的原始使用案例是在軟體開發內容中將複雜的系統模型化。 它最初不是為了建立企業數據模型，而且對於數據管理從業者來說，其方法可以是抽象和技術。 通常對 DDD 缺乏瞭解。 從業者發現其概念概念太難理解或嘗試將軟體架構或面向物件程序設計中的範例投影到其數據環境。 本文提供務實的指引和清楚的詞彙，讓您瞭解和使用 DDD。
網域驅動設計
Domain-Driven 設計由 Eric Evans 引進，是支援軟體開發的方法，可協助描述大型組織的複雜系統。 DDD 很受歡迎，因為許多高階做法會影響新式軟體和應用程式開發方法，例如微服務。
DDD 區分界限內容、網域和子域。 網域是您想要解決的問題空間。 它們是知識、行為、法律和活動聚集在一起的領域。 您會看到網域中的語意結合、元件或服務之間的行為相依性。 網域的另一個層面是通訊。 小組成員必須使用整個小組共用的語言，讓每個人都能有效率地工作。 此共享語言稱為 無處不在的語言 或 網域語言。
網域會分解成子域，以更妥善地管理複雜度。 其中一個常見的例子是將領域分解成對應特定商務問題的子領域，如 將數據網格運用於 AI/ML所示。
並非所有子域都相同。 例如，您可以將網域分類為核心、泛型或支援。 核心子域是最重要的。 他們是使組織與眾不同的秘密醬汁，成分。 泛型子域是非特定專案，通常很容易使用現成的產品來解決。 支援子域不會提供競爭優勢，但必須讓組織保持運作，而且並不複雜。
限定內容是邏輯（內容）界限。 它們著重於解決方案空間：系統與應用程式的設計。 這是一個區域，焦點在解決方案空間上的對齊是合理的。 在 DDD 內，這可以包含程式代碼、資料庫設計等等。 在定義域與限定內容之間，可以對齊，但沒有硬式規則將兩者系結在一起。 限定的內容本質上是技術性的，而且可以跨越多個網域和子域。
領域模型化建議
如果您採用數據網格作為數據大眾化的概念，並實作領域導向數據擁有權原則來增加彈性，則實際上如何運作？ 從企業數據模型轉換為領域驅動設計模型的外觀為何？ 您可以從 DDD 取得哪些課程以進行資料管理？
將問題空間進行功能性商業分解
在允許小組端對端操作其數據之前，請先查看範圍並瞭解您嘗試解決的問題空間。 至關重要的是，您應先進行這項練習，然後再深入了解技術實作的細節。 當您設定這些問題空間之間的邏輯界限時，責任會變得更清楚，而且可以更妥善地管理。
將問題空間分組時，請查看您的商務架構。 在商業架構中，有商業能力：企業擁有或交換的能力或資源，以達成特定的目的或結果。 此抽象概念會將數據、程式、組織和技術納入特定內容，以配合您組織的策略性商務目標和目標。 商務功能地圖會顯示哪些功能區域似乎必須符合您的任務和願景。
您可以在下列模型中檢視虛構公司 Tailwind Traders 的功能分解。
Tailwind Traders 必須掌握業務能力圖中列出的所有功能領域才能成功。 Tailwind Traders 必須能在在線或離線票務管理系統中銷售票證，或在飛行員管理計劃中確保有飛行員可以駕駛飛機。 公司可以外包某些活動，同時將其他活動作為其業務的核心。
您在實務上觀察到的是，大部分的人都是圍繞商務功能進行組織。 處理相同商務功能的人員會共用相同的詞彙。 您的應用程式和流程也是如此，這些應用程式和流程通常根據它們所支援活動的凝聚力來進行良好的對齊和緊密的連接。
業務能力映射是一個絕佳的起點，但您的旅程不會在此結束。
將商務功能對應至應用程式和數據
若要更妥善地管理您的企業架構，請讓商務功能、限定內容和應用程式保持一致。 請務必遵循一些基本原則。
商務功能必須維持在商務層級，並保持抽象。 它們代表貴組織所做的工作，並以您的問題空間為目標。 當您實作商業能力時，會為特定情境創建一個實現（能力實例）。 多個應用程式和元件可在解決方案空間的這類界限內一起運作，以提供特定的商業價值。
與特定商務功能一致的應用程式和元件會與符合其他商務功能的應用程式保持分離，因為它們解決了不同的商務考慮。 界限上下文源自於並專門映射到業務能力。 它們代表商務功能實作的界限，其行為就像網域一樣。
如果商務功能變更，限定內容就會變更。 您最好預期定義域與對應的限定內容之間完全一致，但當您在稍後的章節中瞭解時，現實有時會與理想不同。
如果我們將功能對應至Tailwind Traders，限定的內容界限和網域實作看起來可能會類似下圖。
在此圖表中，客戶管理是以主題專業知識為基礎所建置，因此最清楚哪些數據要用於其他網域。 客戶管理的內部架構已分離，因此這些界限內的所有應用程式元件都可以使用應用程式特定的介面和數據模型直接通訊。
數據產品 和明確的互操作性標準被用來將數據分發格式化至其他網域。 在這個方法中，所有數據產品也會與定義域一致，並繼承無處不在的語言，這是一種建構、正規化的語言，由同一個網域的項目關係人和設計師所同意，以滿足該定義域的需求。
多個功能實現的額外網域
使用業務能力地圖時，請務必確認某些業務能力可以多個實例化。
例如，Tailwind Traders 可能會有多個當地語系化的實現（或應用），例如「行李處理和遺失物品」。假設其業務線之一僅在亞洲運營。 在此背景下，「行李處理和丟失物品」是與亞洲相關的航空得以實現的一項能力。 不同的企業營運可能會針對歐洲市場，在此背景下，會使用另一項「行李處理和遺失物品」功能。 多個實例的這一情況可能會導致多個當地語系化實作，使用不同的技術服務和各自為政的小組來操作這些服務。
商務功能和功能實例（實現）的關係是一對多。 因此，您最終會擁有額外的 （子） 網域。
尋找共用功能並注意共享數據
處理共用商務功能的方式很重要。 您通常會以服務模型的形式集中實作共用功能，並將其提供給不同的企業營運。 「客戶管理」可以是這類功能的範例。 在我們的 Tailwind Traders 範例中，亞洲和歐洲的業務都使用相同的管理來服務客戶。
但是，如何在共用功能上呈現網域資料的所有權？ 多個商務代表可能會對相同共用管理內的客戶負責。
有一個應用程式域和數據域。 您的領域和界限上下文，從數據產品的觀點來看，無法完全對齊。 相反地，您可能會爭辯說，從業務能力的觀點來看，仍然存在單一數據問題。
針對複雜的廠商套件、SaaS 解決方案和舊版系統等共用功能，在網域數據擁有權方法中保持一致。 您可以透過數據產品來隔離數據擁有權，這可能需要應用程式改進。 在我們的 Tailwind Traders「客戶管理」範例中，應用程式域的不同管線可能會產生多個數據產品：所有亞洲相關客戶的一個數據產品，以及所有歐洲相關客戶的一個數據產品。 在此情況下，多個數據域源自相同的應用程式域。
您也可以要求應用程式域建立單一數據產品，以封裝元數據，以區分本身的數據擁有權。 例如，您可以保留擁有權的數據行名稱，將每個數據列對應至單一特定數據域。
識別提供多個業務能力的單體結構
也請注意滿足多種商務功能的應用程式，這些功能經常出現在大型企業和傳統企業中。 在我們的範例案例中，Tailwind Traders使用複雜的軟體套件來促進「成本管理」和「資產與融資」。這些共用應用程式是一體型，可提供盡可能多的功能，使其變得龐大且複雜。 在這種情況下，應用程式域應該更大。 同樣的事情適用於共用擁有權，其中數個數據域位於應用程式域中。
源頭對齊、重新傳遞和消費者對齊領域的設計模式
當您映射網域時，您可以根據資料的建立、消耗或重新傳遞來選擇模式。 針對您的架構，您可以根據網域的特定特性來設計支援網域的範本。
來源系統對應的領域
來源系統匹配的域與數據來源系統對齊。 這些系統通常是交易式或可操作的。
您的目標是直接從這些黃金來源系統擷取數據。 從您提供的網域中取得優化的讀取數據產品，以便于大量數據消耗。 協助這些領域使用標準化服務進行數據轉換和共用。
這些服務包含預先設定的容器結構，可讓您的來源導向網域小組更輕鬆地發佈數據。 這是一條阻力最小的路徑，造成最少的干擾和成本。
消費者對應的網域
消費者對齊的網域與來源對齊的網域相對。 它們與需要其他網域數據的特定終端用戶使用案例相符。 以客戶為中心的領域會取用和轉換數據，以符合貴組織的使用案例。
請考慮提供共用數據服務來進行數據轉換和取用，以滿足這些取用需求。 例如，您可以提供與網域無關的數據基礎結構功能，以處理數據管線、記憶體基礎結構、串流服務、分析處理等等。
重新配送網域
數據的重複使用性是不同且更困難的案例。 例如，如果下游取用者對來自不同網域的數據組合感興趣，您可以建立匯總數據的數據產品，或結合許多網域所需的高階數據。 這可讓您避免重複的工作。
請勿在數據產品與分析使用案例之間建立強相依性。 反而要追求彈性和鬆散耦合。 下列模型示範如何達成彈性。 網域同時擁有數據產品和分析使用案例的所有權，並針對數據產品的創建和使用設計了不同的流程。
定義重疊的網域模式
當跨定義域共用數據或商業規則時，定義域模型化通常會變得複雜。 在大型組織中，網域通常會依賴來自其他網域的數據。 泛用領域可以以提供整合邏輯的方式，使其他子域進行標準化並從中受益，對整個過程很有幫助。 請將子域之間的共用模型保持小巧，並始終與統一語言一致。
針對重疊的數據需求，您可以使用來自領域驅動設計的不同模式。 以下是您可以選擇的模式簡短摘要：
- 如果您偏好重複的成本而不是重複使用，那麼可以使用 個別方式 模式。 可重複使用性因更高的彈性和靈活性而犧牲。
- 如果某個網域強大，並且願意負責下游消費者的數據和需求，那麼可以使用 客戶供應商 模式。 缺點包括抵觸的顧慮，並迫使下游團隊協商交付項目和安排的優先次序。
- 當您的整合邏輯在新建立的網域中以隨機的方式協調時，可以使用 合作關係 模式。 所有團隊都合作，並相互考慮彼此的需求。 因為沒有人可以自由變更共享邏輯，因此每個相關人員都需要做出重大承諾。
- 符合要求的 模式可用於使所有網域都符合所有需求。 當您的整合工作很複雜、沒有其他方能控制，或使用廠商套件時，請使用此模式。
在所有情況下，您的網域都應該遵守您的互操作性標準。 為其他網域產生新數據的合作關係網域，必須像任何其他網域一樣公開其數據產品，包括取得擁有權。
網域責任
數據網格透過將數據擁有權分散到各個領域小組，實現去中心化的數據管理。 對於許多組織來說，這表示從治理的集中式模型轉移到同盟模型。 網域小組會指派工作，例如：
- 取得各數據管線的擁有權，例如擷取、清理和轉換數據，以盡可能滿足數據客戶的需求
- 改善 數據品質，包括遵守數據取用者所設定的 SLA 和品質量值
- 封裝元數據或使用保留的列名稱進行精細的列和行層級篩選
- 遵守元數據管理標準，包括：
- 應用程式和來源系統架構註冊
- 提升搜尋效果的元數據
- 版本控制資訊
- 數據屬性和商務詞彙連結
- 確保 中的元資料 資訊完整性，以便在不同領域之間提供更好的整合
- 遵守數據互操作性標準，包括通訊協定、數據格式和數據類型
- 藉由將來源系統和整合服務鏈接至掃描器，或手動提供譜系來提供譜系
- 遵循數據共享相關任務，包括IAM存取權審查和建立數據合約
解耦的粒度等級
既然您已瞭解如何辨識及促進數據域，您可以瞭解如何設計正確的網域粒度層級和分離規則。 當您分解架構時，有兩個重要維度正在作用中。
功能域和設定限定內容的數據粒度是一個維度。 網域符合特定運作方式，確保數據可供所有使用共用服務、取得擁有權、遵守元數據標準等網域使用。
盡可能為數據分配設定細微的界限。 成為數據導向就是讓數據可供充分重複使用。 如果您讓界限過於鬆散，則強制許多應用程式之間的不想要結合，並失去數據重複使用性。 努力在每次數據跨越業務能力邊界時進行解耦。 在網域內，允許網域內部架構維持緊密耦合。 不過，當跨越商業功能的界限時，領域必須保持分離，並分發讀取優化的數據產品，以便與其他領域共用。
技術網域和基礎結構使用率的粒度是另一個重要維度。 您的 數據登陸區域 提供 資料應用程式所需的靈活性，以創建數據產品。 如何建立這種著陸區域，以便在其之下配備共用的基礎設施和服務？ 功能領域邏輯上被分組在一起，並且是共享平台基礎架構的良好對象。 以下是建立這些登陸區域時需要考慮的一些因素：
- 使用和共享數據時的凝聚力和效率是將功能網域與數據匯聚區域整合的強大推動因素。 這與資料重力有關，指的是在不同領域之間持續共用大型數據產品的傾向。
- 區域界限可能會導致額外的數據登陸區域的實施。
- 擁有權、安全性或法律界限可以強制網域隔離。 例如，其他任何網域都看不到某些數據。
- 彈性和變革速度是重要的驅動因素。 某些領域可以有很高的創新速度，而其他領域則高度重視穩定性。
- 功能界限可以將團隊分開。 其中一個範例可能是來源導向和取用者導向的界限。 一半的網域小組可能會比其他服務更重視某些服務。
- 如果您想要可能出售或區隔您的功能，您應該避免與來自其他網域的共用服務緊密整合。
- 小組大小、技能和成熟度都可能是重要的因素。 高技能且成熟的小組通常會偏好自行操作服務和基礎結構，而較不成熟的小組則較不重視平臺維護的額外負荷。
布建許多數據登陸區域之前，請先查看網域分解，並判斷哪些功能網域是共用基礎結構的候選專案。
總結
商務功能模型化可協助您在數據網格架構中更清楚地辨識及組織您的網域。 它提供數據與應用程式將價值傳遞給您企業的方式的整體檢視，同時協助您排定優先順序並專注於數據策略和商務需求。 您也可以將商業能力建模用於不僅限於數據的範疇。 例如，如果延展性是問題，您可以使用此模型來識別您最重要的核心功能，併為其開發策略。
一些從業者擔心，事先將所有內容規劃清楚來建立目標狀態架構是一項繁重的工作。 相反地，他們建議您在將網域整合到新的數據網格架構時，以自然的方式識別您的網域。 您不必從上而下定義目標狀態，而是從下到下、探索、實驗和將目前狀態轉換為目標狀態。 雖然這個建議的方法可能更快，但它具有重大風險。 當事情開始出錯時，您可能正處於複雜的搬遷或翻修作業中。 從兩個方向出發，自上而下和自下而上，然後在中間匯合，這是一種更細微的方法。