sudotty commented 4 years ago

一个企业需要什么样的架构，才能成为数据驱动？如何在保持敏捷性、安全性和可控性的同时，高效分配数据？现在将解决这些问题，为数据管理奠定基础，并开始构建。

我们所看到的趋势要求我们重新思考数据管理和数据整合的方式。我们已经了解到了在对应用数据进行精确复制时出现的紧密耦合，以及分析的操作化的困难。我们也了解到了构建集成数据仓库的统一问题和巨大的努力，以及它对敏捷性的影响。我们需要做出的转变是，从将所有数据漏斗到一个单一的数据仓中，转向让域、团队和用户能够轻松、安全地分配、消费和使用数据。平台、流程和模式应该简化其他人的工作。我们需要简单、记录良好、快速和易于使用的界面。我们需要一个能在规模上发挥作用的数据管理架构。本章将讨论如何以不同的方式进行数据集成。

我所设想的分层架构侧重于数据管理和数据集成。它是一个针对企业的架构，旨在让团队能够安全、轻松地提供数据，同时保持敏捷性、控制力和洞察力。就像许多其他架构一样，它使用的是架构积木。这些积木将被反复使用，以帮助你认识到我们所讨论的架构的具体部分。

OpenGroup将架构积木定义为 "为满足业务需求而定义的功能包。将功能、产品和定制开发组装成积木的方式在各个架构之间会有很大的差异"。

让我们先来回顾一下，找出最实质性的构件。接下来我们将讨论一些补充文献，并得出一些结论。然后，最后，我们将讨论新的架构及其原理和它的剥离，看看里面有什么。到了最后，你就会明白这些不同的构件是如何工作的，并将其联系在一起。这些背景理论对于理解新架构的核心驱动力是必要的。在随后的章节中，我们将进一步深入到模式、详细设计、图表和工作流程，你将开始了解这个架构是如何将所有的数据管理领域联系在一起的

sudotty commented 4 years ago

汲取的经验教训

数据整合是实现价值的关键。它经常被忽视；它很复杂，但也很关键。没有数据整合，你就无法消费数据，建立新的服务，或向组织提供分析性的洞察力。

应用是特殊的，有其独特的背景

在XREF HERE中，我们了解到应用是用来进行显性活动和解决具体问题的。每个应用程序的数据都是独一无二的，与其他应用程序的数据和上下文不同。我们还了解到应用的设计和开发有几个阶段。我们先从概念思考和设计开始。然后，我们将知识转化为逻辑数据模型，这是概念信息和需求的抽象结构，是一个逻辑数据模型。最后我们做物理数据模型：真正设计出应用和数据库的物理数据模型。物理数据模型是独一无二的，它同时接收了应用和数据库如何设计和使用的上下文和非功能需求。

数据集成的困境是无法回避的

在应用程序之间移动数据时，由于数据创建的特殊上下文，总是需要进行数据集成。无论你是做ETL(Extract, Transform and Load)还是ELT(Extract, Load and Transform)，是虚拟的还是物理的，是批量的还是实时的，都无法摆脱数据整合的困境。当把数据从一个上下文中的数据带入另一个上下文时，总是需要进行数据转换。这个关键词总是会框定新的架构。

应用程序扮演着数据提供者和数据消费者的角色

应用程序要么是数据提供者，要么是数据消费者，正如我们将看到的那样，有时两者都是。一个应用需要使用数据，而另一个应用则创建和提供数据。这可能看起来很明显，但在大量应用和系统中集成数据的背景下，这一点很重要。数据提供者和数据消费者的角色将成为正式的架构构件。

根据系统或应用程序是作为提供者还是消费者，游戏规则会发生变化：适用不同的架构原则。数据提供者和数据消费者的角色也适用于外部方。外部方在企业生态系统的逻辑边界之外运行。它们一般位于独立的、不受控制的网络位置上。我们在第一章中看到，企业将公共网络视为一个数据宝库，他们可以将数据货币化，以创建和共享可重用的服务。这种新的协作方式改变了组织的边界。

我所引入的新架构需要灵活性，让外部各方既是数据的提供者，也是数据的消费者。通常需要额外的安全措施，因为外部方并不总是被信任的、已知的或与更大的上下文直接相关的。

应用程序运行的独特上下文，数据提供者和消费者的角色，以及应用程序之间总是发生的转换，都是新架构中的关键因素。但是，我们还需要考虑什么？怎样才能构成一个好的整体架构？接下来的章节将对这些问题进行探讨。

sudotty commented 4 years ago

主要的理论考虑

应用系统之间的数据集成就是要管理好系统之间的通信复杂性和数据的互操作性。在企业架构中，我们通常会从大局出发。一个应用程序内部的应用组件是如何进行数据集成的，我们可以从中学习到什么？应用集成处于软件架构或软件开发的层面。从抽象的层面上看，企业数据集成和软件集成是紧密联系在一起的，有时会有重叠的地方 dial-size10-Slide1 接下来我们将更仔细地研究一些应用软件的开发模式，这些模式可以为反复出现的问题提供见解。了解它们有助于开发团队避免产生依赖性和复杂性。

sudotty commented 4 years ago

面向对象的编程原则

我们要评估的第一个设计原则是面向对象编程（OOP）。一般来说，管理应用程序和代码的复杂性就是将复杂的逻辑抽象化，为可重复的问题提供通用的功能，并为其他组件提供通用的接口。R.C.Martin的《设计原则和设计模式》（2000年）这本书提供了完美映射到数据集成上的见解。其中的许多设计原则至今仍被应用于常见的实践中。

单一责任原则这个原则是关于设定明确的责任和界限。正如Martin所写的那样，"这个原则是关于人的。你要把你的模块从整个组织的复杂性中分离出来，并设计你的系统，使每个模块都只负责（响应）该业务功能的需求。"
依赖关系倒置原则这一原则指出 "高层不应依赖低层模块。都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象 "，这就是关于隐藏内部的复杂性和细节。抽象比底层逻辑要稳定得多。
开放/封闭原则这个原则指出，"一个模块应该是开放的，可以扩展，但封闭的，可以修改 "3。当我们修改一个函数时，依赖于该函数的所有东西也要进行修改。我们不希望数据交换的改变会引起后续依赖系统或应用的级联改变。
稳定的依赖关系原则这个原则指出，"软件模块依赖的方向是稳定性。稳定性与改变所需的工作量有关 "4.一个应用程序的功能只能建立在至少与自身一样稳定的功能之上。
稳定的抽象原则这个原则指出 "一个组件应该和稳定的组件一样抽象 "5.让稳定的组件抽象化的好处是，你可以很容易地在不违反设计的前提下对其进行扩展。

Martin的软件应用程序设计原则对新架构的启发，因为应用程序通过接口进行通信的方式与应用程序组件在应用程序内部的通信方式类似。如果我们想避免每一次改变接口就会导致应用程序和系统崩溃，那么我们就需要尊重马丁的原则。它们受到了广泛的尊重，并影响了许多开发框架和方法。其中一种叫做领域驱动设计（DDD）。

sudotty commented 4 years ago

领域驱动的设计

领域驱动设计是一种为大型组织开发复杂系统的软件开发方法，最初由Eric Evans 6描述。DDD之所以流行，是因为它的许多高层次实践对现代软件和应用程序开发方法（如微服务）产生了影响。

有界语境

领域驱动设计中的一种模式被称为有界语境。有界语境是用来设置域的解决方案空间的逻辑边界，以更好地管理复杂性。团队要明白哪些方面，包括数据，他们可以自己去改变，哪些是共享的依赖关系，需要和其他团队协调，避免破坏东西，这一点很重要。设置边界可以帮助团队和开发人员更有效地管理依赖关系。

逻辑上的边界一般是显式的，并且在有明确的、内聚力较强的领域上执行。这些领域的依赖关系可以坐在不同的层次上，比如应用的具体部分、流程、关联数据库设计等。我们可以得出结论，绑定的上下文是多态的，可以应用于许多不同的视点。所谓多态性，就是指边界上下文的大小和形状可以根据视点和周围环境的不同而变化。这也意味着你在使用有界上下文的时候需要明确，否则仍然是相当模糊的。

sudotty commented 4 years ago

域和有界语境

DDD区分了有界语境、域和子域。域是我们要解决的问题空间。它们是知识、行为、法则和活动汇聚在一起的领域。它们是我们看到语义耦合的领域：组件或服务之间的行为依赖关系。为了更好地管理复杂性，通常会把领域分解成子领域7。一个常见的例子是将一个域分解成这样一种方式，即每个子域对应于组织的不同部分。

不是所有的子域都是一样的。它们可以被分类为核心子域、通用子域或支持性子域。核心子域是那些最重要的子域。它们是使企业与众不同的秘密酱料和成分。通用型子域是不特定的，一般是用现成的产品很容易解决的。配套子域并不能提供竞争优势，但却是维持组织运行的必要条件。通常情况下，它们并没有那么复杂。

有界的语境是逻辑（上下文）边界。它们专注于解决方案的空间：系统和应用的设计。这是一个聚焦于解决方案空间的对齐的领域，它是有意义的。这可以是代码、数据库设计等。在域和绑定语境之间，可以有对齐，但将它们绑定在一起并不是硬性规定。束缚语境从本质上来说是技术性的，因此可以跨越多个域和子域。

sudotty commented 4 years ago

设置逻辑界限背后的想法是，责任更明确，管理起来也会更好。成员之间的沟通效率很高，因为同样的人都在为类似的目标而努力。在软件上设置逻辑边界在某种程度上类似于单一责任原则，即属于一起的东西应该留在一起（并且应该有效管理）。

在企业层面上，我们在逻辑上将具有高度凝聚力或共同利益的应用程序组合在一起。这种共同利益通常位于业务任务和职责的凝聚力层面。有些人将其称为功能域、逻辑组、群组或组织能力。将实体、流程或应用程序分组在一起并不是什么新鲜事。

传统的 "传统 "分组与域驱动设计模式的最大区别在于域驱动设计的强制、严格的边界。Evans认为，有边界的上下文可以独立演化，但必须解耦。解耦通常是通过隐藏或抽象化，将复杂的应用内部功能隐藏起来，并确保接口和层达到一定的稳定性。这些原则类似于依赖倒置和稳定依赖原则。

无处不在的语言

"Ubiquitous Language "是Eric Evans在领域驱动设计中使用的术语，指的是在开发者和用户之间建立一种共同的、严谨的语言的做法。8 "根据Martin Flower的说法。这种语言类似于特定领域内人们使用的定义、词汇、行话或术语。通用语言有助于将大团队内部的人联系起来，因为在一个大团队或企业内部，往往更难统一在同一或单一的语言上。为了避免团队之间过多的交叉交流和不一致的术语，通用语言被用来支持一个领域内的应用程序或软件的设计。因此，并没有一个统一的语言，尽管可能会有重叠。

绑定上下文和泛在语言有很强的关系，因为在DDD中，每个绑定上下文都会有自己的泛在语言。在一个有界上下文中，属于一起管理的应用程序或应用组件，都应该遵循相同的语言。如果一个有界上下文不断增长，对团队的理解成为一个挑战，那么这个有界上下文可以被分解成更小的部分。如果绑定的语境发生了变化，无处不在的语言也应该是不同的。拇指规则是，通常一个绑定上下文由一个（敏捷或DevOps）团队管理，因为在一个团队内，所有团队成员更容易了解当前的情况和所有的依赖关系。

当我提出有边界的上下文时，我经常把它和文化进行比较，以明确不同团队之间的定义和术语是不一样的。语境是具体的，通常是基于我们所知道的情况。每个有界语境都有不同的目标，不同的背景，最主要的是不同的文化。文化在很大程度上决定了我们的思维方式、设计方式和模式。在一个文化内部，也存在着亚文化：在一个更广泛的文化中，有一群有共同目标和实践的人。同样的论点也适用于领域驱动的设计。一个有界语境可以由多个子域或多个有界语境建立起来。同样，在数据建模部分的XREF HERE中，我们看到，应用程序的设计和数据模型从其使用的域中接受上下文。所有这些设计方法都是紧密联系在一起的。

领域驱动的设计方法使用有边界的上下文来设置独立领域的边界，具有较高的凝聚力。如果我们将DDD投射到企业级的应用场景中，那么域的边界不仅将应用保持在一起，而且还将语言、知识、团队资源和技术保持在一起。如图2-2所示，我们期望每个边界上下文都有自己的应用、数据、流程和上下文定义（泛在语言）。

用应用作为边界的缺点是，在企业层面上听起来还是有点抽象。在更大的架构中，是什么将元素和组件凝聚在一起？典型的问题是如何为企业设计和开发应用的问题。这就把我们带到了下一个方法论，也就是业务架构。

sudotty commented 4 years ago

业务架构

一个精心设计的业务架构对于成功地追求企业架构是至关重要的。业务架构协会将业务架构描述为 "代表了整体的、多维度的业务观点，包括：能力、端到端价值交付、信息和组织结构；以及这些业务观点与战略、产品、政策、举措和利益相关者之间的关系 "。架构师以业务架构为基础，设定企业及其业务生态系统的原则、指导思想、期望结果和边界。业务架构是通过构建一个整体性的、多维度的业务视图与业务能力的支撑。从有界语境中我们可以得出业务架构和业务能力的并列关系。另一种使用有界语境的方法是通过业务架构的视角来看待有界语境。

业务能力

为了解决业务问题和满足需求，常用的技术是为每个业务目标创建对象，称为业务能力。业务能力是业务架构中使用的一个构件。正如Ulrich Homann所说的那样，业务能力是 "企业为实现特定的目的或结果而可能拥有或交换的特定能力或能力。"业务能力为企业创造价值，以实现企业的战略业务目标或业务目标。它们捕捉并描述了数据、流程、组织和技术（DPOT）之间在特定环境下的关系。

注

业务能力模型以结构化的表象或可视化的方式，代表了组织的整体战略业务目标和活动。每个业务能力至少要实现一次。这个模型还可以用来映射和绘制依赖关系。例如，将数据管理的关键绩效指标映射到已实施的业务能力上，可以显示出数据管理的有效性及其对组织的影响。

用来设定逻辑边界的边界上下文，可以与业务架构相一致。在最高的概念层面，我们将所有的战略业务目标映射到业务能力上，并将其归纳为业务能力和价值流。在应用架构上再低一个层次，就形成了一个蓝图，一个更具体的架构。在这个蓝图中，你可以画出逻辑（解决方案）边界，可以看成是有边界的上下文，代表着业务架构的功能和应用部分以及业务架构的实现。应用及其组件用来实现业务能力的特定技术维度。

sudotty commented 4 years ago

领域域边界和粒度

设定准确的边界和粒度不是严格的科学。它是一门艺术，并且伴随着启发式的方法。对于数据管理和企业的规模和复杂度，我喜欢把领域边界映射到业务架构的逻辑边界上。其他人更多的是看组织边界、业务流程或领域专业性。另一种看领域边界的方法是通过绘制出你的软件架构的详细蓝图，确定哪些应用组件应该是比较松散的耦合或者是强关联的应用组件。特别是在微服务中，这种技术相对来说是比较流行的。

如果你想更好地理解领域边界是什么，以及如何准确地设置绑定上下文，我鼓励你看一看领域故事会、事件风暴和绑定上下文画布。这些技巧都是关于理解域的复杂性，学习域内发生的事情，以及如何结构化域。

业务架构中的业务能力仍然是抽象的，可以多次实现。当实例化时，它被称为能力实例。为了帮助大家更好地理解，我制作了一个业务能力和相应的能力实例的组织实例。

例如，客户关系管理(CRM)作为一种业务能力，可以为零售和企业业务部门实施。同样的业务能力，也可以作为一种服务模式集中实施，提供给多个部门。是联合还是集中，只是一个选择的问题。例如，在需要控制的时候，比如安全或合规性等方面，集中实施CRM可能是比较好的选择。在每个业务部门内部实施CRM可能更可取，当团队有不同的动态或利益冲突时，在每个业务部门内部实施CRM可能更可取。

业务能力并不能说明组织结构、组织边界以及能力是内部开发还是外包。它们也可以在组织内部或组织间独立移动。例如，一个在线支付服务最初可以在内部开发，但在后来的某一时刻又外包给了PayPal。这种组织变化不应该影响到业务能力。为了实现企业的目标，处理在线支付的具体能力不变。

sudotty commented 4 years ago

将业务能力与应用联系起来

业务能力、能力实例、有边界的上下文和应用都可以联系起来。在这样做的时候，一定要遵循一些基本规则。至关重要的是，业务能力要停留在业务层面，并保持抽象。它们代表了一个组织所做的事情，并针对问题空间。当一个业务能力被实现时，就会为特定的上下文创建一个实现--能力实例。在解决方案空间的这些边界内，多个应用和组件可以协同工作。值得一提的是，逻辑应用边界是有框架的：应用只允许为一个能力实例服务。它们不能跨越或同时服务于多个能力实例。这些应用的整个集合，在能力实例的边界内，形成一个有边界的上下文。数据和流程也是如此--它们也是内聚的。

对于应用来说，两种观点结合起来进行综合分解。一个应用，本身仍然是抽象的。它是一个逻辑边界，应用组件可以在其中构建或部署。而应用组件，相对于应用而言，是有形的。它们有大小、组成，并存在于上下文技术中。例如，一个应用模块，打包后部署成JAR文件，是一个非常有形的工件。

把这两种不同的观点结合起来，可以带来很多价值。在应用层面，我们可以把业务能力、产品负责人、DevOps团队、项目等连接起来。在应用组件层面，我们可以连接IT产品、版本、配置项、合同、维护计划等。

在业务能力和应用架构之间有了关系，就会有很多好处。它使接口和应用解耦的准则更加清晰。它有助于更好地执行数据治理；你可以认为，所有在特定上下文中为特定业务能力创建的数据都属于特定的（产品）所有者。产品所有权和数据所有权突然变得更加一致。我们也可以在能力层面上更好地得出结论，因为应用与能力有明确的联系。

当将业务能力及其实例映射到一个有边界的上下文并生成蓝图时，多个应用可以协同工作，以完成相同的业务需求。在图中，可以看到，为了完成CRM的战略目标，有三个应用紧密地协同工作。在这些应用的周围，或者说在这些应用内部，我们画出适用性、范围和责任的具体边界。在该领域的解决方案空间的逻辑边界内的应用或应用组件应该共享相同的无处不在的语言，并允许直接通信。应用或应用组件之间应该有比较紧密的耦合；但是，当边界的上下文边界被跨越时，可以观察到不同的域，就会触发警报：需要解耦。

sudotty commented 4 years ago

有些人使用的术语是业务服务：业务的逻辑分组，在面向服务的体系结构中定义的业务逻辑分组，涉及到表示业务逻辑。能力实例是业务能力实现驻留在其中的逻辑边界。业务服务是一种实现细节：服务作为一种标准化的通信方式。

sudotty commented 4 years ago

通过连接不同的模型，我们可以实施明确的原则。有界语境源于业务能力，并专门映射到业务能力。如果业务能力发生了变化，绑定上下文也会发生变化。早前你已经了解到，绑定上下文是解耦的，通过接口或层来说话。间接来说，这意味着业务能力也必须解耦。不代表同一实例化业务能力的应用程序、数据和流程不允许直接与另一个实例化业务能力的应用程序进行交互。相反，应用程序在与其他应用程序对话时，必须隐藏其内部逻辑。让我们用一个案例分析来描绘这个理念。

业务架构实践中的业务架构：一个案例研究

例如，假设一家律师事务所确定了三个明确的业务目标，并将其映射到业务能力上。

法务管理业务能力记录了所有正式的法律文件和不同的案件。不同的应用、流程和数据都属于法律管理绑定语境。
客户管理业务能力，就是客户管理业务能力，对客户进行管理。所有的客户信息、邮件往来、信件、录音电话都在这个系统中进行管理。客户管理绑定语境就代表了这一切。
营销业务能力已经外包给了外部公司，由营销绑定语境来代表。

如果我们在每个能力实例周围画一个逻辑边界，那么每个绑定上下文都有明确的范围，使用自己的无处不在的语言，并且是解耦的。解耦意味着不与其他绑定上下文的内部应用逻辑直接通信。绑定的上下文通过解耦的接口或抽象进行通信。当数据由绑定上下文提供时，采用无处不在的语言进行通信。这在逻辑上意味着，当客户端管理绑定上下文中的系统进行通信时，客户端管理的泛在语言作为通信语言。在这个模型中，数据消费者要将数据直接转化为自己的上下文。

sudotty commented 4 years ago

业务架构模式

在图中，一个外部方将其能力作为服务提供给其他有边界的语境。构建平台的商业模式，将这些服务外包给其他公司，并在商业模式上共同合作，这就是所谓的生态系统。这样的生态系统通常由多个参与者组成。

我们可以确定在商业生态系统中出现的一些沟通模式。

第一步：应用到应用之间的沟通共享相同的绑定上下文和无处不在的语言的应用程序，可以直接进行通信。所有团队成员都应该了解绑定语境中的耦合点。

第二步：域与域之间的通信跨越边界的应用沟通，是解耦的，因为不同的边界语境服务于不同的关注点，使用不同的无处不在的语言。

第三步：内部到外部的通信跨越边界的应用通信，在边界约束上下文和内部可信环境中的应用通信，都是通过额外的安全措施来解耦的。内部信任环境也可以被认为是有边界的上下文，因为外部方不可能总是被信任。需要采取额外的安全措施来促进这种形式的通信。

在这个例子中，来自不同域的应用直接进行通信。这种模式也被称为点对点集成。在接下来的章节中，我将评估这种和其他一些应用通信形式背后的理论。

sudotty commented 4 years ago

沟通和整合模式

在进入解决方案之前，我想先简单讨论一些数据分发通信模式和方法。在处理更大规模的应用时，可以使用一些通信模式来连接应用和组合数据。其中有些你已经很熟悉了。在XREF HERE中，你已经了解了构建企业数据消费的单片机应用的孤岛式方法。

点对点第一种模式是点对点通信，它允许从一个应用直接通信到另一个应用。点对点接口产生了我所说的紧密耦合的反模式，这使得体系结构的复杂性迅速增长到完全混乱，如图所示。

为了说明这个混沌，我们来做个小计算。如果有多个应用，每个应用都有连接，那么将有大约(n-1)2/2个点对点连接。这意味着，对于管理100个应用程序，大约有5000个点对点连接。对于1,000个应用，大约有500,000个点对点连接。点对点连接无法提供企业所需要的控制和敏捷性，因为通信通道的数量太多，几乎不可能监督所有的依赖关系。

Silos

点对点通信的替代方案是通过将所有的数据和应用集成逻辑集中在一起，建立筒仓。筒仓的优势是快速获取所有数据，但在大型企业的规模上，使用筒仓进行数据分发并不能提供敏捷性。

在软件工程的背景下，我并不反对构建筒仓。模块化，与单片式相反，它增加了复杂性，并引入了一致性问题。单片式的应用架构将应用逻辑更紧密地捆绑在一起，当有很强的内聚性和（事务性）完整性要求时，这可能是有益的。所以，构建孤岛会很适合某些场景。

它为你提供了很多不一致的地方，需要巨大的集成努力。在XREF HERE中，你了解到数据孤岛是组织无法真正利用数据的关键原因之一，因为需要付出巨大的整合和协调努力。

集线器和辐条模型

使用点对点连接或构建数据孤岛的替代方案是集线器和辐条模型。其想法是建立一个中央分布式中枢，或称层，将不同系统和应用的接口连接起来。

将数据汇集在一起的方法在概念上看起来与筒仓相似，但却有明显的不同，因为这里的数据并不是集成的，而是与其他数据混合在一起。在图2-6所示的集线器和辐条架构中，应用不直接进行通信。通信总是通过中央集线器进行。每个应用首先要连接到集线器：随后，其他应用在连接后就可以进行通信。

集线器-辐条模型本身并没有明确规定其通信语言。它可以从单一的企业语言到非承诺的标准化形式，不一而足。它也没有明确说明集成发生在哪里：在数据交付到集线器之前、期间或之后。数据交付枢纽和数据代理架构这两个术语也被用于这种模式。

我认为，当从集中式的、单片式的数据集成架构向域驱动的数据分发模式转变时，我认为集线器-辐条模型有很大的好处。分层架构可以看作是枢纽-辐式模型，但考虑到了碎片化和孤岛的风险。

sudotty commented 4 years ago

分层架构

第1章中讨论的趋势表明了为什么需要一个新的架构。

虽然技术总是在不断变化，但数据提供者和数据消费者的基本概念以及移动和转换数据的需求不会消失。企业需要的是一个可扩展的架构，它可以轻松地连接数据提供者和数据消费者，同时提供灵活性、控制力和洞察力。

新的集成架构还必须简化工作，使团队能够有效地协作和沟通。它必须为大量的用例提供模式。它也不应该强迫企业管理复杂的点对点景观或紧密耦合的数据孤岛。企业需要一个架构，让他们能够在企业范围内管理依赖性和分离关注点。

分层架构结合了我多年来收集到的经验教训和新的见解。运营一个企业数据管理和集成架构需要标准化模式，遵循明确的设计原则，并做出艰难的选择。在接下来的章节中，我将从基本的设计选择开始，逐步揭示最重要的模式和原则。

金源和集成数据存储

分层架构的第一个原则是：只允许黄金源系统中的黄金数据集分布。黄金源，就像你在XREF这里学过的那样，黄金源是指所有原始的原始数据都是在特定的边界范围内创建的应用。这些独特的数据将被链接到黄金数据集上，黄金数据集是用于对数据进行分类的技术表征，确保数据可以与所有权、（安全）分类、上下文等联系在一起。

在XREF这里，你会详细了解到这是如何工作的，但现在重要的是，重要的是，相同的唯一数据可以在整个架构中多次分布。因此，在脱离孤岛式的组织方式时，对独特数据进行分类和识别是非常重要的。黄金源和黄金数据集可以确保数据分布时的一致性和责任性。我们甚至可以用以下原则来更严格地制定。

原则1：只有在黄金源处才会发生变化对黄金数据集及其元素的修改，只有在域内的黄金源处，经所有者批准后，才能进行修改。

原则2: 只提供黄金数据集只有最初生成的数据（黄金数据集）才能从黄金源系统中交付。

原则3：黄金数据集是一个应用的子集。黄金数据集起源于一个应用程序，因此不能跨越多个应用程序。

原则4：黄金数据集和元素集中登记，以便于发现。为了提供透明度和信任，重要的是通过工具和平台集中提供黄金数据源和所有权元数据----关于数据的数据----的数据。这需要所有的域集中注册其独特的黄金数据集和元素，并相应地将其与产生和暴露的数据链接起来。

接下来，我们来介绍一下集成数据存储（IDS）。集成数据存储与金源系统不同的是，集成数据存储是对其他系统的数据进行消耗、整合和改变上下文。这种情况下的数据(如图2-7所示)来自于其他地方，在集成数据存储的约束上下文之外。

sudotty commented 4 years ago

对黄金源或综合数据存储进行分类很重要，因为这样做可以明确黄金数据集的责任和来源。它还可以保证数据在整个数据分发链中保持唯一性和相同。

在图左边，你可以看到应用A，数据的源头：这是黄金源系统。其中一个数据集被不同的应用程序B消耗，这个例子中的应用程序B是集成数据存储。

当一个集成数据商店创建新的黄金数据集时，它可以成为一个新的黄金源。在这种情况下，数据真正有了新的上下文，所以有了新的事实。我们也会期望有新的所有权。这就引出了我们接下来的三个原则。

原则5：新的数据导致新的所有权当数据被改变并创建了新的事实时，就会产生新的所有权。简单的 "语法转换"，如过滤器、联合、联合、合并、大小写转换、字段重命名和聚合等，都不会产生新的所有权，因为事实保持不变。

原则6：不允许再进行黄金数据集分配 IDS所使用的黄金数据集，未经所有者或数据安全团队批准，不得向其他域分发。

原则7：不需要的时候不要创建IDS 应避免未经管理的黄金数据集的副本，因为它们的维护成本很高，而且难以控制。数据集成是复杂的；用户在没有太多数据的时候，必须避免维护提取或副本。只有当新创建的数据需要存储时，才有理由从RDS中提取数据并存储在数据消费方的位置上。

需要理解的是，IDS可以同时扮演数据消费者和数据提供者的角色。在这种情况下，集成的数据商店以消费者的角色，对数据进行消费、整合，并将数据转化为新的黄金数据集。作为提供者，它将新创建的黄金数据集提供给其他数据消费者。我在图中进行了可视化的描述。

对黄金源或综合数据存储进行分类很重要，因为这样做可以明确黄金数据集的责任和来源。它还可以保证数据在整个数据分发链中保持唯一性和同一性。

数据交付合同和数据共享协议数据的消费、整合和分发的方式，需要数据提供者和数据消费者之间签订合同，约定选择什么样的数据，下游如何消费，用于什么目的。接下来的原则是。

原则8：数据分发和消费通过合同来保障数据的分发和消费通过数据交付合同和数据共享协议，保证了提供和消费数据的责任方面。

数据交付合同类似于服务合同，它为数据提供者和数据消费者提供了保证。数据提供者承诺进行交付，并描述了数据的消费方式。该合同保证接口的兼容性，并包括服务条款和服务级别协议（SLA）。服务条款描述了数据的使用方式，例如，只能用于开发、测试或生产。SLA描述了数据交付和接口的质量。这可能包括正常运行时间、错误率和可用性，以及过时、路线图和版本号。

数据提供商可以使用不同版本的数据交付合同同时交付数据。图. 数据提供者可以使用不同版本的数据交付合同同时交付数据。数据交付合同的好处是，它提供了对应用程序之间的耦合和依赖性数量的洞察力。它还可以进行合同测试，确保所有的应用和接口变化都能根据消费者的数据要求进行验证。

数据共享协议是关于预期的使用、隐私和目的（包括限制）。它们让人们了解到哪些数据被用于什么特定目的。数据消费者需要登记并公布其数据消费的各种用例的目的，并同意不进一步分发数据。这不仅从监管的角度来看很重要，而且会给数据提供者提供有价值的信息。

数据交付合同和数据共享协议很关键，因为它们能让企业了解数据供应链的情况，并让企业了解服务级合同、控制措施、数据质量规则和数据的使用情况等方面的透明度。这些合同需要存储在中央存储库中，这是新架构的一个正式的构件。集中发布这些合同可以让供应商和消费者自己解决数据交付和消费问题，而不需要中央团队的支持。一旦我们开始摆脱集中式、单一化和孤岛式的数据平台方式，并将更多的任务交给团队，这就变得至关重要。

sudotty commented 4 years ago

数据交付合同的好处是，它提供了对应用程序之间的耦合和依赖性数量的洞察力。它还可以进行合同测试，确保所有的应用和接口变化都能根据消费者的数据要求进行验证。

数据共享协议是关于预期的使用、隐私和目的（包括限制）。它们让人们了解到哪些数据被用于什么特定目的。数据消费者需要登记并公布其数据消费的各种用例的目的，并同意不进一步分发数据。这不仅从监管的角度来看很重要，而且会给数据提供者提供有价值的信息。

数据交付合同和数据共享协议很关键，因为它们能让企业了解数据供应链的情况，并让企业了解服务级合同、控制措施、数据质量规则和数据的使用情况等方面的透明度。这些合同需要存储在中央存储库中，这是新架构的一个正式的构件。集中发布这些合同可以让供应商和消费者自己解决数据交付和消费问题，而不需要中央团队的支持。一旦我们开始摆脱集中式、单一化和孤岛式的数据平台方式，并将更多的任务交给团队，这就变得至关重要。

消除孤岛式的做法

分层架构的第一个设计选择是，企业数据仓库将被淘汰。数据孤岛是企业无法真正发挥数据优势的主要原因之一：数据孤岛需要额外的转化步骤，这使得提供者和消费者之间的链条变长，管理难度大大增加。在数据仓库模型中，我们不得不处理不一致的问题，因为有边界的上下文经常会发生冲突。数据仓库模型中的数据提供者和数据消费者是紧密耦合的，这使得依赖关系的管理难度大大增加。因为数据孤岛的数据质量问题、修正和不一致的问题，数据孤岛往往不被信任。由于发布窗口较长，敏捷性是最大的问题。

在DDD模型中，新的工作方式是直接进行上下文转换，只需要一个上下文转换步骤。数据将直接从一个上下文转移到另一个上下文中。这种单一的转换步骤意味着数据提供者和消费者不再共享一个单一的企业典范模型（词汇表）。每个绑定上下文使用自己的通用语言提供数据。消耗者绑定的上下文接收数据并直接将其转化为自己的上下文。通过不再有一个企业级的典范模型，我们避免了我们在仓库模型中的定义和不同版本的真相之间的不一致。通过从一个上下文直接转移到另一个上下文，我们创造了最大的价值，因为每个人都能获得最准确的数据，接近数据的来源地。

这种模式的缺点是，团队在消费数据时，必须更好地理解许多不同的上下文。他们不再学习企业模型的单一词汇，而是突然面临着解释许多不同语境的问题。这就需要强有力的原则来约束域如何向其他域提供数据。它们必须易于消费，并为数据整合做好准备。

读取优化的数据

将数据从一个上下文转移到另一个上下文中总是很困难，因为它需要两个上下文的知识。另一个问题是，一般情况下，应用程序并没有针对密集的数据消耗进行优化。架构往往是高度规范化的，业务逻辑隐藏在数据中，或者文档缺失。为了缓解数据集成的痛苦，我们需要为数据如何从一个有边界的上下文到另一个有边界的上下文中暴露和呈现数据设定一些原则。

原则21：隐藏应用技术细节这个原则很像依赖关系倒置原则（XREF HERE），影响到数据的提供方式，因为在向其他数据消费者提供数据的时候，希望从数据中抽象出内部的复杂性。从应用的角度来看，这意味着数据提供者被要求过滤掉任何应用逻辑，需要对应用的具体知识进行过滤。数据消费者不需要成为物理数据模型的专家，也不应该要求数据消费者重建应用功能来使用数据。这个原则还涉及到我们通常在应用中发现的技术数据，比如迁移信息、日志信息或数据库模式等信息。这些技术数据是特定的，可能只对内部领域有兴趣。数据提供商应该在公开之前，过滤掉任何不会有兴趣的数据。

原则22：针对密集型数据消耗进行优化。许多应用并没有针对密集的数据消耗进行优化。为数据整合做好准备，并不意味着大量的标准化数据与无尽的父子结构。数据应该更多地进行去规范化，并直观地分组在一起。用户友好的字段名称将帮助数据消费者找到他们要找的东西。命名规范和数据格式的不一致和差异，希望在前期就能解决。这种方法中的数据必须为通用消费进行优化，目的是尽可能多地方便潜在的数据消费者。

原则23：无处不在的语言是沟通的语言作为数据提供者的每个有边界的上下文都应该使用自己的泛在语言来公开其数据。这意味着数据提供者不允许将其他域的业务逻辑纳入到自己的域中。

原则24：接口必须具有一定的成熟度和稳定性这个原则是关于抽象化变化的速度。例如，如果域范围经常发生变化，那么抽象到稳定的范围就会被期待。该模式还必须提供稳定的兼容性。

原则25。在所有不同的模式中，数据应该是一致的这一原则要求数据在不同的模式之间的暴露方式保持一致。例如，字段客户地址，即使同一数据多次暴露在不同的模式中，也应该保持一致。

拉入自描述、用户友好的数据的方法与许多数据湖的实现方式有明显的不同。在数据湖(XREF HERE)中，数据一般都是直接从源头直接拉入，作为一对一的拷贝。数据和接口与底层源系统紧密耦合，因此任何源系统的改变都会立即中断生产流水线。正因为如此，企业很难成功地将高级分析系统运营化。

从这些原则中，我们可以得出的结论是，数据提供商应该以更友好、更好的消耗性和逻辑性的方式来暴露自己的数据。必须避免原始数据所带来的重复性工作。数据应该以 "逻辑业务模型 "的抽象版本来表示，而不是应用中的纯物理数据模型。在第6章中，我会给出更具体的指导，什么是好的数据表示方式。

本节中的原则可以强烈尊重，也可以松散尊重。对于临时性的、探索性的、实验性的用例，接口可以比较不稳定，也可以不那么优化直接消费。而对于稳定的生产，则应严格遵循这些原则。你甚至可以通过让系统进行组合来混合这些方法：例如，一组数据的传递要强烈地尊重这些原则，而另一组数据，可能不那么有趣，但传递的是比较松散的数据。