1. 域和服务

1.1. 域是你正在为其构建的现实世界主题区域

1.2. 服务是一组功能，其目标是完成一项任务

1.3. 一个域可以包含多个服务

1.4. 确定领域中应包含的内容

• 1.4.1. 确定领域应该包含什么以及要包括哪些服务时，最好的建议是简单地去与用户和利益相关者交谈，倾听他们在说什么，并构建将帮助他们完成工作的服务

• 1.4.2. 要避免在真空中进行架构设计的经典陷阱

2. 可扩展性

2.1. 允许我们增加系统的容量以提高性能和处理需求

2.2. 单台机器上可能的资源有硬性限制

3. 弹性

3.1. 一个可扩展系统动态扩展的能力

3.2. 一个高弹性的系统可以根据当前的工作负载自动扩容和缩容

3.3. 随着需求的增加，扩大规模至关重要，而缩小规模则可以在云环境中节省资金

3.4. 现代系统有时会缩放到零，这意味着它们可以在空闲时自动关闭

3.5. 动态缩放有助于在没有工程师手动干预的情况下确保足够的性能

• 3.5.1. 弹性提高可靠性

4. 可用性

4.1. IT服务或组件处于可操作状态的时间百分比

4.2. 单机通常无法提供高可用性和可靠性

5. 可靠性

5.1. 系统在指定时间间隔内执行其预期功能时满足规定标准的概率

5.2. 低可靠性会导致低可用性

6. 分布式系统

6.1. 利用分布式系统来实现更高的整体扩展能力以及更高的可用性和可靠性

6.2. 水平扩展允许你添加更多机器以满足负载和资源需求

6.3. 水平扩展系统有一个主节点，作为工作负载实例化、进度和完成的主要联系点

6.4. 典型的现代分布式架构也内置冗余

6.5. 分布式系统的管理细节通常被抽象出来，使你可以专注于高级架构而不是低层次管道

7. 紧耦合与松耦合

7.1. 紧耦合

• 7.1.1. 可以选择拥有较为集中的依赖项和工作流

• 7.1.2. 领域和服务的每个部分都非常依赖于其他领域和服务

7.2. 松耦合

• 7.2.1. 拥有分散的领域和服务，它们彼此之间没有严格的依赖性

• 7.2.2. 在松耦合的情况下，分散的团队很容易构建其数据可能无法被同行使用的系统

• 7.2.3. 确保为拥有各自领域和服务的团队分配共同的标准、所有权、责任和义务

7.3. 设计“好的”数据架构依赖于领域和服务的紧耦合和松耦合之间的权衡

8. 架构层次

8.1. 单层

• 8.1.1. 在单层架构中，你的数据库和应用程序紧耦合，驻留在单个服务器上

• 8.1.2. 该服务器可以是你的笔记本电脑或云中的单个虚拟机(Virtual Machine，VM)

• 8.1.3. 紧耦合的性质意味着如果服务器、数据库或应用程序出现故障，则整个架构都会失败

• 8.1.4. 单层架构适用于原型设计和开发，但由于明显的故障风险，因此不建议将其用于生产环境

• 8.1.5. 单层架构适用于在本地计算机上测试系统，但不建议用于生产用途

• 8.1.6. 单层架构提供了简单性，但也有严重的局限性

8.2. 多层

• 8.2.1. 通过解耦数据和应用程序解决了紧耦合单层架构的挑战

• 8.2.2. 多层（也称为n层）架构由单独的层组成：数据、应用程序、业务逻辑、展示等

• 8.2.2.1. 将数据与应用程序分离，并将应用程序与展示分开

• 8.2.3. 这些层是自底向上和分层的，这意味着下层不一定依赖于上层

• 8.2.3.1. 上层依赖于下层

• 8.2.4. 三层架构由数据层、应用程序/逻辑层和表示层组成

• 8.2.4.1. 每一层都相互隔离，允许关注点的分离

• 8.2.4.2. 使用三层架构，你可以在每一层中自由使用你喜欢的任何技术，而无须集中精力

• 8.2.5. 数据工程师应该使用层来评估他们的分层架构和处理依赖关系的方式

• 8.2.5.1. 考虑你是否希望节点出现资源争用

>  8.2.5.1.1. 如果不是，则使用无共享架构：单个节点处理每个请求，这意味着其他节点不与该节点或彼此共享内存、磁盘或CPU等资源

• 8.2.5.2. 节点是否应该共享所有节点都可以访问的相同磁盘和内存

>  8.2.5.2.1. 共享磁盘架构

8.3. 单体

• 8.3.1. 单体内部的耦合

• 8.3.1.1. 技术耦合

>  8.3.1.1.1. 技术耦合指的是架构层次

• 8.3.1.2. 领域耦合

>  8.3.1.2.1. 领域耦合指的是领域之间耦合在一起的方式

• 8.3.2. 单体在技术和领域之间具有不同程度的耦合

• 8.3.3. 单体的紧耦合意味着其组件缺乏模块化

8.4. 微服务

• 8.4.1. 微服务架构包括独立的、分散的和松耦合的服务

• 8.4.2. 每个服务都有一个特定的功能，并且与在其领域内运行的其他服务解耦

• 8.4.3. 单体不是一蹴而就的，它是一个技术问题，也是一个组织问题

8.5. 注意事项

• 8.5.1. 中央数据仓库本质上是庞大的

• 8.5.1.1. 向与数据仓库等效的微服务的转变是将拥有特定领域数据管道的工作流连接到相应的特定领域数据仓库进行解耦

• 8.5.2. 务实地将使用松耦合作为一种理想，同时认识到你在数据架构中使用的数据技术的状态和局限性

• 8.5.3. 以垂直方式将架构的组件分为不同的关注层

• 8.5.4. 集中化：一个团队负责从所有领域收集数据并协调它以供整个组织使用

• 8.5.5. 数据网格

• 8.5.5.1. 使用数据网格，每个软件团队负责准备其数据以供组织的其他部门使用

• 8.5.6. 单体不一定是坏的，在某些条件下从单体开始可能是有意义的

• 8.5.6.1. 从单体开始要简单得多

• 8.5.6.2. 准备好最终将其分解成更小的部分

9. 用户访问

9.1. 多租户

• 9.1.1. 所有云服务都是多租户的，尽管这种多租户出现在不同的粒度上

• 9.1.1.1. 云计算实例通常位于共享服务器上，但虚拟机本身提供了一定程度的隔离

• 9.1.1.2. 对象存储是一个多租户系统，但只要客户正确配置其权限，云供应商就可以保证安全性和隔离性

• 9.1.2. 工程师经常需要在更小的范围内做出有关多租户的决策

• 9.1.2.1. 来自不同租户的数据必须适当隔离

• 9.1.2.2. 数据隔离策略因系统而异

• 9.1.2.3. 必须确保视图不会泄漏数据

10. 事件驱动架构

10.1. 一个事件驱动的工作流包含在数据工程生命周期的各个部分创建、更新和异步移动事件的能力

10.2. 主要领域

• 10.2.1. 事件生产

• 10.2.2. 路由

• 10.2.3. 消费

10.3. 事件驱动架构的优势在于它将事件的状态分布到多个服务中

11. 棕地项目

11.1. 棕地(Brownfield)项目通常涉及重构和重组现有架构，并受到现在和过去的选择的限制

11.2. 最好是深入挖掘、提出问题并理解做出决策的原因

11.3. 同理心和上下文在帮助你诊断现有架构的问题、发现机会和识别陷阱方面大有帮助

11.4. 直接重写的一种流行替代方法是绞杀者模式：新系统缓慢地、逐步地替换遗留架构的组件

11.5. 如果你在一个大型组织中，根除遗留技术或架构可能是不可能的

12. 绿地项目

12.1. 绿地(Greenfield)项目让你开创一个全新的开始，不受先前架构的历史或遗留问题的限制