架构师训练营第十周学习总结

• 单体应用系统规模和复杂度达到一定程度时，会出现各种问题，如编译、部署困难，代码分支管理困难，数据库连接耗尽，新增业务困难等，为了解决这些问题，可以考虑采用微服务框

• 微服务框架需要满足以下需求：

• 负载均衡

• 失效转移，以实现服务高可用

• 高效的远程通信

• 对应用最少侵入

• 版本管理

• 升级接口不会导致服务调用失败

• 容忍接口请求者不升级

• 微服务落地实践过程中，必须业务线性，理顺业务边界和依赖关系，根据需求制定开发原则，选择最佳实践和实现工具

• 领域驱动设计中，领域模型合并了行为和数据的领域的对象模型，通过领域模型对象的交互完成业务逻辑的实现，也就是说设计好了领域模型对象，也就设计好了业务逻辑实现，称为充血模型

• 领域驱动设计的关键术语：

• 领域：一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。

• 子域：领域是一个组织所做的事情以及其包含的一切。这个范围就太大了，不知道该如何下手。所以通常的做法是把整个领域拆分成多个子域，比如用户、商品、订单、库存、物流、发票等。

• 限界上下文：在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文通常和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性。

• 上下文映射图：不同的限界上下文，也就是不同子域之间会有各种的交互合作。DDD 使用上下文映射图来设计这种关联和交互。

• 实体：领域模型对象也被称为实体，每个实体都是唯一的，具有一个唯一标识，一个订单对象是一个实体，一个产品对象也是一个实体，订单ID 或者产品ID 是它们的唯一标识。实体可能会发生变化，比如订单的状态会变化，但是它们的唯一标识不会变化。

• 值对象：并不是领域内的对象都应该被设计为实体，DDD 推荐尽可能将对象设计为值对象。比如像住址这样的对象就是典型的值对象。

• 聚合：聚合是一个关联领域对象的集合，我们将其作为一个单元来处理数据更改。每个集合都有一个根和一个边界。边界定义了聚合内部的内容。根是聚合中包含的单个特定实体。

• 领域驱动设计典型开发过程与关键产出：

• 产品经理

• 需求文档/业务场景

• 事件风暴

• 业务流程图及用例

• 业务词汇表

• 限界上下文及概念模型

• 架构师进一步设计

• 领域模型

• 架构师/开发

• 微服务拆分/技术架构设计