需求是第一
分析一个架构时需要倒三角模型，微服务也不例外。第一重要是需求，其次看方案是否可以带来的价值，需要遵循什么原则，使用技术的最佳实践有哪些，最后是选择可以使用哪些工具。
基于网关的微服务架构
基于网关的微服务架构是主流的微服务架构方式。
网关做接口适配调用不同的微服务。
通常网关里没有业务逻辑。一般只做数据转换、数据包装等。
收到请求后，网关调用微服务，微服务调用其他微服务，完成业务处理。最后网关包装数据返回给应用。
除了基本的数据包装，网关还可以进行流量管控、限流、降级、安全防护等。
领域驱动设计 DDD
为什么需要DDD
- 项目实际情况，产品经理需求零零散散。RD在代码里修修补补，导致代码没有真正的设计。
项目时间一长，添加需求的成本逐步增高。
如何解决已有问题
以后的编码方式有两种：事务脚本 和 领域模型
事务脚本
业务在service中，每增加一种情况，会导致service中加一个if else分支。
随着业务的扩展，sevice变的非常的庞大。
领域模型
按照面向对象的方式，设计类和对象。关于对象本身的计算由对象本身完成。
贫血模式 vs 充血模型
事务脚本模式，Service、Dao的对象只有方法，没有数据成员。方法调用时，传递数值对象（没有方法），因此事务脚本又叫做贫血模型。
领域模型的对象包括了对象的数据和计算逻辑，是真正的面向对象。通过领域模型的对象交互完成业务逻辑。即，设计好了领域模型的对象，就设计好了业务逻辑实现。和贫血模型相对应的，领域模型被称为充血模型。
事务脚本，散落各处，bug不知如何寻找。
领域模型，所有逻辑内聚在方法内部，容易排查。
明显的，充血模型优于贫血模型。为了更好的实现领域驱动DDD，为支撑领域模型的一套方法手段。为领域模型提供了更多的方法模型，更多的实践。
某种意义上来说，只要实现领域模型，就是DDD。无论是否使用了DDD，或者是只使用了部分DDD。
领域驱动设计DDD
DDD战略设计
子域
所有的事情都要属于子域的。由子域去完成领域的业务。每个子域应该做什么？需要思考。
如：卖家提现功能应该放到哪个子域？开始可能放到了卖家子域，后来发现和对账相关，需要放到财务子域。再后来，发现放财务中也没有那么好。
子域分析，是DDD战略中的重要部分。子域就是微服务。一个子域就是一个微服务。
限界上下文
在一个子域汇总，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。限界上下文和子域有一对一的关系，用来控制子域边界。
上下文映射
不同的限界上下文，也就是不同的子系统或模块之间会有各种交互，DDD使用上下文映射图设计交互。
随着对业务理解的逐步深入，和需求的逐步增多，可能使核心概念过期，需要调整模型映射。
DDD战术设计
实体
实体即领域模型对象。每一个实体都是唯一的。因此，要有一个唯一标识ID。
实体设计是DDD的核心所在，业务分析识别出实体对象。
值对象
不是所有对象都是实体。值对象没有ID，不会改变。不变的东西设计成值对象。
聚合
关联对象的集合，一个实体不可能自己完成业务的处理，要和其他的对象结合。
DDD战略设计与战术设计
通过战略设计理清关系，划分模块与服务的边界及依赖关系，对微服务架构设计至关重要。
甚至可以不做战术设计，只做战略设计。
DDD六边形模型
领域模型通过应用程序封装成一个独立的模块。不同的外部系统通过不同的适配器和领域模型交互。
