数据管理指南

有界上下文是领域驱动设计的核心模式。这是DDD的战略设计部分的重点，这是关于处理大型模型和团队的。DDD处理大型模型的方法是将它们划分到不同的有界上下文中，并明确它们的相互关系。

通用语言是埃里克·埃文斯在领域驱动设计用于在开发人员和用户之间建立一种通用的、严格的语言的实践。这种语言应该基于域模型在软件中使用——因此它需要是严格的，因为软件不能很好地处理模糊性。

我使用术语应用程序数据库(Application Database)来表示由单个应用程序控制和访问的数据库IntegrationDatabase)。由于只有一个应用程序访问数据库，因此可以对数据库进行特定的定义，以使一个应用程序的需求易于满足。这导致了一个更具体的模式，它通常更容易理解，而且通常不那么复杂IntegrationDatabase．

许多企业正在投资他们的下一代数据湖，希望大规模民主化数据，以提供业务洞察，并最终做出自动化智能决策。基于数据湖体系结构的数据平台具有常见的故障模式，导致无法大规模实现承诺。华体会体育网页版入口要解决这些故障模式，我们需要从集中的湖泊范式或其前身数据仓库转变。我们需要转换到从现代分布式体系结构中汲取的范式:将域视为第一类关注点，应用平台思维创建自助式数据基础设施，并将数据视为产品。华体会体育网页版入口

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

由于NoSQL数据库是新出现的，并且引起了越来越多的兴趣，我和Pramod Sadalage认为，缺乏对该技术的体面介绍，使得从业者很难就是否以及如何使用它们做出正确的决定。因此，我们写了一个简短(152页)的概述，涵盖了数据模型、分布式数据的问题、一致性的思考、模式迁移，以及几个不同风格的NoSQL数据库示例。

2012年，goto会议邀请我以一场关于NoSQL数据库的介绍性演讲开始他们的NoSQL轨道。我介绍了twitter meetup的标签定义背后的共同特征，讨论了常见的NoSQL数据模型，以及分布式数据存储系统中关于一致性的问题。虽然它涵盖了类似的领域我们的书，但如果你更喜欢简短的视频概述，它是一个合理的总结。(这是我最受欢迎的演讲，在YouTube上的视频点击量超过75万。)

当我们开始工作的时候Nosql蒸馏我们面临着一个棘手的难题——我们要写什么?NoSQL数据库到底是什么?现在还没有明确的概念定义，没有商标，没有标准的团体，甚至没有一个宣言。

近年来，关于无模式数据的优点的讨论越来越多。无模式是感兴趣的主要原因之一NoSQL数据库．但是在数据库和内存数据结构方面，无模式涉及到许多微妙之处。这些微妙之处既体现在无模式的含义上，也体现在使用无模式方法的优缺点上。

我们设计这本书的时候，NoSQL蒸馏，我们在大部分章节的结尾都总结了一些要点，以作为读者重新阅读这本书的复习。我们将这些内容放在网站上，以另一种方式提醒读者注意这些要点。

这是我们工作时首先想到的话题之一Nosql蒸馏NoSQL数据库使用不同于关系模型的数据模型。我看过的大多数来源都至少提到了四组数据模型:键值、文档、列族和图。看一下这个列表，前三者之间有很大的相似之处——它们都有一个基本的存储单元，这是一个密切相关的数据的丰富结构:键值存储是值，文档存储是文档，列族存储是列族。在DDD术语中，这组数据是一个DDD_Aggregate．

“大数据”已迅速跃升为我们行业中最被炒作的术语之一，但这种炒作不应蒙蔽人们的一个事实，即这是数据在世界上所扮演角色的真正重要转变。数据源的数量、速度和价值正在迅速增加。数据管理必须在五个方面发生变化:提取来自更广泛来源的数据的变化物流数据管理与新的数据库和集成方法的使用敏捷运行分析项目的原则，强调数据技术解释要将信号从噪声中分离出来，设计精良的重要性不言而喻可视化让这个信号更容易理解。综上所述，我们不需要大型的分析项目，相反，我们希望新的数据思维渗透到我们的日常工作中。

我们在2012伦敦QCon上的主题演讲着眼于数据在我们生活中所扮演的角色(它所做的不仅仅是变得更大)。我们首先看看数据世界是如何变化的:它在增长，变得更加分布式和连接。然后我们转向行业的回应:NoSQL的兴起，向服务集成的转变，事件来源的出现，云的影响，以及对可视化发挥更大作用的新分析。我们将快速浏览一下目前数据是如何被使用的，丽贝卡将特别强调发展中国家的数据。最后，我们考虑这一切对我们作为软件专业人员的个人责任意味着什么。

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

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

我记得在我十几岁的时候，有人告诉我人工智能(AI)在未来几年将会做很多了不起的事情。现在,一些几十年后来，其中一些似乎正在发生。最近的一次胜利是计算机通过对弈来教彼此下围棋，迅速变得比任何人类都熟练，其策略人类专家几乎无法理解。人们很自然地想知道未来几年将会发生什么，计算机会很快拥有比人类更大的智能吗?(鉴于最近的一些选举结果，这可能不是一个很难跨越的障碍。)

但当我听到这些时，我想起了毕加索几十年前对计算机的评论:“计算机是无用的。他们只能给你答案。”像机器学习这样的技术所能产生的推理在其结果中是真正令人印象深刻的，并且将对作为软件用户和开发人员的我们很有用。但答案虽然有用，却并不总是全貌。我在上学的早期就知道了这一点——仅仅提供一个数学问题的答案只能让我得到几个分数，而我必须出示的是满分如何我得到了它。得到答案的推理比结果本身更有价值。这是自学成才的围棋人工智能的局限性之一。虽然他们能赢，但他们无法解释自己的策略。

2006年，我的同事尼尔·福特(Neal Ford)创造了这个术语通晓多种语言的编程，以表达应该用混合语言编写应用程序的想法，以利用不同的语言适合处理不同的问题这一事实。复杂的应用程序组合了不同类型的问题，因此为工作选择正确的语言可能比试图将所有方面都放到一种语言中更有成效。

在过去的几年里，人们对新语言的兴趣激增，特别是函数式语言，我经常想花些时间钻研Clojure、Scala、Erlang或类似的语言。但我的时间有限，我将优先考虑另一个更重要的转变，那就是DatabaseThaw．第一批资金已经从客户和其他联系人那里获得，前景非常诱人。我可以自信地说，如果您开始一个新的战略企业应用程序，您不应该再假设您的持久性应该是关系的。关系选项可能是正确的选项——但是您应该认真地考虑其他选项。

大多数EnterpriseApplications用数据库存储持久数据。该数据库支持应用程序状态的操作更新，以及用于决策支持和分析的各种报告。然而，操作需求和报告需求通常是截然不同的——不同的需求来自于不同的模式和不同的数据访问模式。当这种情况发生时，将报告需求分离到报告数据库中通常是一个明智的主意，该数据库获取基本操作数据的副本，但用不同的模式表示它。

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

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

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

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

当人们开始一个企业应用程序时，最早的问题之一是“我们如何与数据库通信”。如今，他们可能会问一个稍微不同的问题:“我们应该使用哪种数据库——关系型数据库还是NOSQL数据库?”但还有另一个问题需要考虑:“我们到底应该使用数据库吗?”

软件系统的一个常见特性是允许用户在数据结构中定义自己的字段。考虑一个地址簿——你可能想要添加很多东西。随着每天都有新的社交网络出现，用户可能想要为他们的联系人添加一个新的Bunglr id字段。