DDD & Microserivces——读书笔记

1 为什么人们将DDD与Microservices两个技术词语绑定在一起？

DDD是一种架构设计设计方法，其想法是让软件的实现与一个演进的架构模型保持一致，而这个演进的模型来自于业务需求。

Martin Flower和James Lewis总结的能够持续演进的大型复杂系统所具备的9大核心特质就是Microservices架构所拥有的特质。

可见一个是架构设计方法，一个是架构，都从业务需求出发，试图让软件实现随着业务多元变化而与时俱进。它们存在因果联系，所以人们经常把二者联系在一起。

2 从业务视角分离复杂度

面对高复杂度时，人们会做关注点分离。一般可从业务维度或技术维度进行关注点分离。比如技术维度分离——MVC分层思想，业务维度分离——按售前、销售、售后划分。

Microservices架构更强调从业务维度的关注点分离来应对高复杂度。传统SOA的ESB是一个典型的从技术关注点分离的中间件。它封装了大量的业务规则和流程，成为了复杂度之源，以至于破坏了SOA架构之前承诺的各种优势。ESB是一种架构上的反模式。

本质上作为一种架构设计方法的DDD和作为一种架构风格的Microservices都是为了追求高响应力目标而从业务视角去分离复杂度的手段。

3 业务和技术渐进统一的架构设计

架构设计简化为三个层面的工作以及它们传统意义上的负责人

• 业务架构（业务人员）：根据业务需求设计业务模块及交互关系。
• 系统架构（架构师/TL）：根据业务需求设计系统和子系统的模块。
• 技术架构（开发人员）：根据业务需求决定采用的技术及框架。

DDD的核心诉求就是让业务架构和系统架构形成绑定关系，这样一来当我们去响应业务变化调整业务架构时，系统架构的改变也会随之发生。

这个变化的结构有两个：
业务架构的梳理与系统架构的梳理是同步渐进的，其结果是划分出的业务上下文和系统模块结构是绑定的。
技术架构是解耦的，可以根据划分出来的业务上下文的系统架构选择最合适的实现技术。

4 跨职能协作的架构设计

DDD成功运用的基础就是创造让业务和系统这两种不同认知模型逐步统一的环境。

Event Stroming模式化协作工作坊是一种让不同背景人协作起来进行架构设计的方式。

5 永无终止的DDD和演进的Microservices

成功的DDD方法运用时贯穿系统的整个生命周期的，这个过程中业务和技术的协作是持续发生的。

[备注]Microservices的9大特质

• 组件以服务形式来提供：正如其名，微服务也是面向服务的。
• 围绕业务功能进行组织：微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着关完整实现的软件，它包含使用接口、持久存储、以及对旬的交互。因此团队应该是跨职能的，包含完整的开发技术：用户体验、数据库、以及项目管理。
• 产品不是项目：传统的开发模式，是至力于提供一些被认为是完整的软件。一旦开发完成，软件将移交给维护或者实施部门，然后，开发组就可以解散掉了。而微服务要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，同时承担一些售后支持。越小的服务粒度越容易促进用户与服务提供商之前的关系。Amazon 的理念就是“You build, you run it”，这也正是 DevOps 的文化理念。
• 强化终端及弱化通道：微服务的应用致力松耦合和高内聚，它们更喜欢简单的REST 风格，而不是复杂的协议（如WS或者BPEL或者集中式框架）。或者采用轻量级消息总线（如 RabbitMQ 或 ZeroMQ 等）来发布消息。
• 分散治理：这是跟传统的集中式管理很大区别的地方。微服务把整体式框架中的组件，拆分成不同的服务，在构建它们时将会有更多的选择。
• 分散数据管理：当整体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。
• 基础设施自动化：云计算，特别是 AWS 的发展，减少了构建、发布、运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化，毕竟发布工作相当的无趣。近些年开始火爆的 Docker 也是一个不错的选择（可以参阅《简述 Docker》）。
• 容错性设计：任务服务都可能因为供应商的不可靠而故障。微服务应为每个应用的服务及数据中心提供日常故障检测和恢复。
• 改进设计：由于设计会不断更改，微服务所提供的服务应该能够替换或者报废，而不是要长久的发展的。