資料管理指南

界定脈絡是領域驅動設計中的核心模式。它是 DDD 策略設計區段的重點，而該區段完全在於處理大型模型和團隊。DDD 透過將大型模型分割成不同的界定脈絡，並明確說明它們的相互關係，來處理大型模型。

無所不在的語言是 Eric Evans 在 領域驅動設計 中用來描述開發人員和使用者之間建立共同嚴謹語言的實務。這種語言應基於軟體中使用的 領域模型，因此需要嚴謹，因為軟體無法很好地應對模糊性。

我使用「應用程式資料庫」一詞來表示由單一應用程式控制和存取的資料庫（與 整合資料庫 相反）。由於只有單一應用程式存取資料庫，因此可以特別定義資料庫以輕鬆滿足該應用程式的需求。這會產生更具體的架構，通常比 整合資料庫 的架構更容易理解，而且通常較不複雜。

許多企業正投資於其下一代資料湖，希望大規模民主化資料，以提供商業見解，並最終做出自動化的明智決策。基於資料湖架構的資料平台具有常見的故障模式，導致無法大規模實現承諾。為了解決這些故障模式，我們需要從資料湖或其前身資料倉庫的集中式範例轉變。我們需要轉向從現代分散式架構中汲取靈感的範例：將領域視為首要考量、應用平台思維來建立自助服務資料基礎架構，並將資料視為產品。

以業務能力為中心的團隊是一個長期與業務特定領域保持一致的團隊。只要所述業務能力與業務相關，團隊就會存在。這與專案團隊不同，專案團隊只會持續到專案範圍交付為止。

在 NoSQL 資料庫新穎且引起興趣時，Pramod Sadalage 和我認為缺乏對這項技術的適當介紹，讓從業者難以對是否以及如何使用它們做出正確的決定。因此，我們撰寫了一份簡短（152 頁）的概觀，涵蓋資料模型、分散式資料問題、一致性思考、架構遷移，以及不同風格的 NoSQL 資料庫的幾個範例。

2012 年，goto 會議要求我以關於 NoSQL 資料庫的介紹性演講來開始他們的 NoSQL 軌道。我介紹了形成 twitter 聚會標籤定義的共同特徵，討論了常見的 NoSQL 資料模型，以及分散式資料儲存系統中的一致性問題。雖然它涵蓋了與我們的書類似的基礎，但它沒有深入探討，但如果你喜歡簡短的影片概觀，這是一個合理的摘要。（這是我的最受歡迎的演講，goto YouTube 影片的觀看次數超過 750,000 次。）

當我們開始撰寫Nosql 精華時，我們立即面臨一個棘手的難題 - 我們在寫什麼？什麼是 NoSQL 資料庫？對於這個概念沒有明確的定義、沒有商標、沒有標準小組，甚至沒有宣言。

近年來，關於無架構資料優勢的討論越來越多。無架構是對NoSQL 資料庫感興趣的主要原因之一。但是，無架構涉及許多微妙之處，無論是資料庫還是記憶體中資料結構。這些微妙之處存在於無架構的含義以及使用無架構方法的優缺點中。

當我們設計這本書時，NoSQL 精華，我們在大部分章節中都總結了一些重點，作為重新閱讀本書的人的複習。我們已將它們包含在網站上，作為讀者提醒自己這些重點的另一種方式。

在我們撰寫精餾 NoSQL時，首先想到的主題之一是 NoSQL 資料庫使用與關聯模型不同的資料模型。我所看過的大部分資料來源至少提到四組資料模型：鍵值、文件、欄位家族和圖形。檢視此清單，前三者有很大的相似性，它們都有一個基本儲存單位，是一個緊密相關資料的豐富結構：對於鍵值儲存，它是值；對於文件儲存，它是文件；對於欄位家族儲存，它是欄位家族。在 DDD 術語中，這組資料是一個DDD_Aggregate。

「大資料」已迅速躍升為我們產業中最受炒作的術語之一，但炒作不應讓人們忽略這是一個關於資料在世界中角色的真正重要轉變。資料來源的數量、速度和價值正在快速增加。資料管理必須在五個廣泛領域中改變：從更廣泛的來源萃取資料、資料管理的後勤因新的資料庫和整合方法而改變、在執行分析專案時使用敏捷原則、強調資料詮釋技術以區分訊號和雜訊，以及精心設計的視覺化的重要性，以使訊號更易於理解。總結來說，這表示我們不需要大型分析專案，而是希望新的資料思考方式滲透到我們的日常工作中。

我們在 QCon London 2012 的主題演講中探討了資料在我們生活中扮演的角色（而且它所做的不只是變得更大）。我們從探討資料世界如何改變開始：它的成長、變得更分散和更緊密連結。然後我們轉移到產業的回應：NoSQL 的興起、轉向服務整合、事件來源的出現、雲端和新分析的影響，以及視覺化扮演更重要的角色。我們快速瀏覽資料現在如何被使用，特別強調 Rebecca 在開發中國家的資料。最後我們考慮所有這些對我們身為軟體專業人員的個人責任有何意義。

資料湖是本十年出現的一個術語，用來描述大數據世界中資料分析管線的重要組成部分。這個想法是要有一個單一儲存庫，用於組織中任何可能需要分析的所有原始資料。一般來說，人們使用 Hadoop 來處理湖中的資料，但這個概念比 Hadoop 更廣泛。

Datensparsamkeit 是德語單字，很難適當地翻譯成英文。它是我們擷取和儲存資料的態度，表示我們應該只處理我們真正需要的資料。

我記得在我十幾歲的時候，有人告訴我人工智慧 (AI) 在未來幾年會做很多很棒的事情。現在過了幾十年，其中一些事情似乎正在發生。最近的勝利是電腦透過互相對弈來學習下圍棋，它們的技術迅速變得比任何人都厲害，策略是人類專家難以理解的。我們自然會好奇未來幾年會發生什麼事，電腦很快就會比人類更聰明嗎？（根據最近幾次的選舉結果，這可能不是太難達到的門檻。）

但是當我聽到這些消息時，我回想起畢卡索在幾十年前對電腦的評論：「電腦沒用。它們只能給你答案」。機器學習等技術可以產生的推理結果令人印象深刻，而且對我們這些軟體使用者和開發人員來說很有用。但是答案雖然有用，卻不總是全貌。我在學校早期的時候就學到了這一點 - 只提供數學問題的答案只能得到幾分，要得到滿分，我必須展示我是如何得到答案的。得到答案的推理比結果本身更有價值。這是自學圍棋 AI 的限制之一。雖然它們可以獲勝，但它們無法解釋自己的策略。

2006 年，我的同事尼爾·福特創造了 多語言程式設計 一詞，表達了應用程式應該使用多種語言編寫的想法，以利用不同語言適合解決不同問題的事實。複雜的應用程式結合了不同類型的問題，因此選擇適合這項工作的語言可能比嘗試將所有方面都塞進一種語言中更有生產力。

在過去幾年中，人們對新語言，特別是函數式語言的興趣激增，我經常很想花一些時間深入研究 Clojure、Scala、Erlang 等語言。但我的時間有限，而且我更優先考慮另一個更重要的轉變，也就是 DatabaseThaw。第一批客戶和其他聯絡人已經陸續出現，前景誘人。我敢肯定地說，如果你正在啟動一個新的策略性企業應用程式，你就不應該再假設你的持久性應該是關聯式的。關聯式選項可能是正確的選擇 - 但你應該認真考慮其他替代方案。

大多數企業應用程式會使用資料庫儲存持續性資料。此資料庫支援應用程式狀態的運作更新，以及用於決策支援和分析的各種報告。然而，運作需求和報告需求通常截然不同，在架構和資料存取模式上都有不同的需求。發生這種情況時，通常明智的做法是將報告需求分隔到報告資料庫中，此資料庫會複製必要的運作資料，但會以不同的架構呈現。

「戰爭與和平」是一本很棒的書。

「讓我看看... 可惜這本書的封面破破爛爛的」

這兩個句子都使用了「書」這個字。我們每天都會瀏覽這樣的組合，卻沒有注意到「書」這個字在每個句子中的意思完全不同。

幾個月前我在倫敦參加 QCon 會議時，似乎每場演講都包含一些關於物件/關聯性對應 (ORM) 工具的尖酸評論。我想我應該更仔細閱讀寄給講者的會議電子郵件，裡面肯定有什麼東西告訴我們每 45 分鐘至少要對 ORM 嗤之以鼻一次。但正如你所見，我想對這種討厭 ORM 的現象做點反擊，因為我覺得其中有許多是不合理的。

當人們啟動企業應用程式時，最早出現的問題之一就是「我們如何與資料庫對話」。現在他們可能會問一個稍微不同的問題「我們應該使用哪種類型的資料庫，關聯式資料庫還是這些 NOSQL 資料庫之一？」。但還有另一個問題需要考慮：「我們應該使用資料庫嗎？」

軟體系統中常見的功能是允許使用者在資料結構中定義自己的欄位。考慮一下通訊錄，有很多東西是你可能想要新增的。隨著每天都有新的社群網路冒出來，使用者可能想要為他們的聯絡人新增一個 Bunglr ID 的新欄位。