数据管理指南

限界上下文是领域驱动设计中的一个核心模式。它是 DDD 战略设计部分的重点，该部分完全是关于处理大型模型和团队的。DDD 通过将大型模型划分为不同的限界上下文并明确它们之间的相互关系来处理大型模型。

通用语言是 Eric Evans 在领域驱动设计中使用的术语，用于在开发人员和用户之间建立一种通用、严谨的语言。这种语言应该基于软件中使用的领域模型——因此需要它严谨，因为软件不能很好地处理歧义。

我使用术语“应用数据库”来指代由单个应用程序控制和访问的数据库（与集成数据库相对）。由于只有一个应用程序访问数据库，因此可以专门定义数据库，以便轻松满足该应用程序的需求。这将导致更具体的模式，该模式通常更容易理解，并且通常比集成数据库的模式简单。

许多企业正在投资于他们的下一代数据湖，希望大规模地实现数据民主化，以提供业务洞察力，并最终做出自动化的智能决策。基于数据湖架构的数据平台具有常见的故障模式，这些模式会导致大规模的承诺无法兑现。为了解决这些故障模式，我们需要从以湖泊或其前身数据仓库为中心的集中式范式转变。我们需要转向一种借鉴现代分布式架构的范式：将领域视为第一要务，应用平台思维来创建自助服务数据基础设施，并将数据视为产品。

以业务能力为中心的团队是指其工作长期与某个业务领域保持一致的团队。只要上述业务能力与业务相关，该团队就会一直存在。这与项目团队形成对比，项目团队只持续到交付项目范围所需的时间。

由于 NoSQL 数据库是新兴的并且引起了人们的兴趣，Pramod Sadalage 和我觉得缺乏对这项技术的良好介绍使得从业者很难就是否以及如何使用它们做出明智的决定。因此，我们写了一篇简短的（152 页）概述，涵盖了数据模型、分布式数据的问题、一致性思考、模式迁移以及不同风格的 NoSQL 数据库的几个例子。

2012 年，goto 大会邀请我以一场关于 NoSQL 数据库的介绍性演讲来开始他们的 NoSQL 专题讨论。我介绍了构成推特聚会标签背后定义的共同特征，讨论了常见的 NoSQL 数据模型，以及分布式数据存储系统中围绕一致性的问题。虽然它涵盖的内容与我们的书相似，但没有深入到相同的程度，但如果你喜欢简短的视频概述，这是一个合理的总结。（这是我最受欢迎的演讲，goto YouTube 视频的观看次数超过 75 万次。）

当我们开始撰写NoSQL 精粹时，我们遇到了一个棘手的难题——我们到底在写什么？NoSQL 数据库究竟是什么？这个概念没有明确的定义，没有商标，没有标准组织，甚至没有宣言。

近年来，关于无模式数据的优势的讨论越来越多。无模式是人们对NoSQL 数据库感兴趣的主要原因之一。但是，无模式涉及许多微妙之处，无论是在数据库方面还是在内存数据结构方面都是如此。这些微妙之处存在于无模式的含义以及使用无模式方法的优缺点中。

当我们设计NoSQL 精粹这本书时，我们在大多数章节的结尾都总结了一些要点，作为读者重读本书时的复习资料。我们在网站上也包含了这些要点，作为读者提醒自己这些要点的另一种方式。

当我们撰写NoSQL 精粹时，首先想到的主题之一是 NoSQL 数据库使用与关系模型不同的数据模型。我查阅的大多数资料都提到了至少四类数据模型：键值、文档、列族和图。仔细观察这份清单，你会发现前三者之间有很大的相似之处——它们都有一个基本的存储单元，它是一个由密切相关的数据组成的丰富结构：对于键值存储，它是值；对于文档存储，它是文档；对于列族存储，它是列族。用 DDD 的术语来说，这组数据是一个DDD 聚合。

“大数据”已迅速跃升为我们行业中最热门的词汇之一，但这种炒作不应该让人们忽视一个事实，即这是数据在世界中作用的真正重大转变。数据源的数量、速度和价值正在迅速增长。数据管理必须在五个广泛的领域发生变化：从更广泛的来源提取数据、使用新的数据库和集成方法改变数据管理的物流、在运行分析项目中使用敏捷原则、强调解释数据的技术以区分信号和噪声，以及精心设计的可视化以使信号更容易理解的重要性。总而言之，这意味着我们不需要大型分析项目，而是希望新的数据思维能够渗透到我们的日常工作中。

我们在 2012 年伦敦 QCon 大会上的主题演讲着眼于数据在我们生活中所扮演的角色（它所做的不仅仅是变得越来越大）。我们首先看看数据世界是如何变化的：它正在增长，变得更加分散和互联。然后，我们转向行业的反应：NoSQL 的兴起、向服务集成的转变、事件溯源的出现、云的影响以及更加重视可视化的新分析。我们快速浏览了数据目前的使用方式，Rebecca 特别强调了发展中国家的数据。最后，我们考虑所有这一切对我们作为软件专业人员的个人责任意味着什么。

数据湖是近十年来出现的一个术语，用于描述大数据世界中数据分析管道的重要组成部分。其理念是为组织中任何可能需要分析的人提供所有原始数据的单一存储库。人们通常使用 Hadoop 来处理湖中的数据，但这个概念比 Hadoop 更广泛。

Datensparsamkeit 是一个德语单词，很难准确地翻译成英语。这是我们如何捕获和存储数据的一种态度，即我们应该只处理我们真正需要的数据。

我记得在我十几岁的时候，有人告诉我人工智能 (AI) 在未来几年会做出多么奇妙的事情。现在几十年过去了，其中一些似乎正在发生。最近的胜利是计算机通过相互对弈来学习下围棋，并迅速变得比任何人类都更加熟练，其策略是人类专家难以理解的。人们很自然地会想知道未来几年会发生什么，计算机是否很快就会拥有比人类更高的智能？（鉴于最近的一些选举结果，这可能不是一个难以逾越的障碍。）

但当我听到这些时，我想起了巴勃罗·毕加索几十年前对计算机的评论：“计算机毫无用处。它们只能给你答案”。机器学习等技术所能产生的推理能力在其结果方面确实令人印象深刻，并且对我们作为软件的用户和开发者来说将非常有用。但答案虽然有用，但并不总是完整的画面。我在上学初期就学到了这一点——仅仅提供数学题的答案只能让我得到几分，要得到满分，我必须展示我是如何得到答案的。得出答案的推理过程比结果本身更有价值。这就是自学成才的围棋 AI 的局限性之一。虽然它们可以获胜，但它们无法解释自己的策略。

2006 年，我的同事 Neal Ford 提出了“多语言编程”一词，以表达应用程序应该用多种语言编写的想法，以便利用不同语言适合解决不同问题的优势。复杂的应用程序结合了不同类型的问题，因此为工作选择合适的语言可能比尝试将所有方面都纳入一种语言更有效率。

在过去的几年里，人们对新语言（尤其是函数式语言）的兴趣激增，我经常想花时间钻研 Clojure、Scala、Erlang 或类似的语言。但我的时间有限，我正在优先考虑另一个更重要的转变，即数据库解冻。第一批成果已经从客户和其他联系人那里传来，前景十分诱人。我可以自信地说，如果您要启动一个新的战略性企业应用程序，您不应该再假设您的持久化应该是关系型的。关系型选项可能是正确的选择——但您应该认真考虑其他选择。

大多数企业应用程序都使用数据库来存储持久性数据。该数据库支持应用程序状态的操作更新，以及用于决策支持和分析的各种报表。但是，操作需求和报表需求通常有很大差异——对架构的要求不同，数据访问模式也不同。发生这种情况时，通常明智的做法是将报表需求分离到报表数据库中，该数据库获取基本操作数据的副本，但以不同的架构表示它。

“《战争与和平》是一本很棒的书。

“让我看看……可惜这本书的封面这么破旧”

两句话都使用了“书”这个词。我们每天都会浏览这样的组合，却没有注意到“书”这个词在每个句子中的意思都完全不同。

几个月前，我在伦敦参加 QCon 大会时，似乎每场演讲都包含一些对对象/关系映射 (ORM) 工具的尖刻评论。我想我应该更仔细地阅读发送给演讲者的会议电子邮件，毫无疑问，其中有一些内容告诉我们所有人每 45 分钟至少要对 ORM 表示一次蔑视。但正如您所知，我想稍微反驳一下这种对 ORM 的憎恨——因为我认为其中很多都是没有根据的。

当人们启动企业应用程序时，最早的问题之一是“我们如何与数据库对话”。如今，他们可能会问一个稍微不同的问题：“我们应该使用哪种数据库——关系型数据库还是这些 NoSQL 数据库中的一种？”但还有另一个问题需要考虑：“我们是否应该使用数据库？”

软件系统中的一项常见功能是允许用户在数据结构中定义自己的字段。以地址簿为例——您可能想添加很多东西。随着每天都有新的社交网络涌现，用户可能希望为他们的联系人添加一个 Bunglr ID 的新字段。