微服务架构二三事

就现阶段而言，DDD已经成为微服务设计的事实标准，也不排除未来可能是有更好的微服务设计标准。
这篇文章聚焦于传统的架构应该如何过渡到微服务架构。

• 传统三层架构
• 传统的DDD分层架构
• 依赖倒置的DDD分层架构
• DDD 五层架构
• DDD 六层架构
• 六边形架构
• 整洁架构-洋葱模型

传统的三层架构

人往往会忽视简单和习以为常的东西，就比如“好好学习”这句话。
三层架构是所有架构的基石和鼻祖，当若干年之后人们再会想架构的时候，首先想到的应该是三层架构。我们应当向三层架构致敬.
正如我前面的提到的《分解》，软件开发的核心原则是分解。今天是这个分解，明天是那个分解，分解和分解之间的不同是维度的不同

根据奥卡姆剃刀原则，如果一个问题有两个模型可以解释，那么肯定选择最简单的那个模型。
想到霍金提到的一个例子

两者都是正确的宇宙模型，人们既可以假定地球静止，也可以假定太阳静止来解释星球的运转，只是哥白尼的日心说具有比较简洁的优势，可以用简单的运动方程来解释太阳系行星的运转。因为用地心说来描述星球的运行将非常复杂，不但要考虑天体的旋转，还要考虑地球的自转，因此托勒密虽然制作了以地球为中心的模型，很多现象依然无法解释，不得不用偏心圆和小轮体系来进行修正.

简而言之，地心说本身没有问题，只是在解释宇宙的时候更复杂，不如日心说那么简单. 这个道理通用适用于三层架构模型。

三层架构不考虑实现，仅仅从概念上来说是完美的。

• 数据库 - 代表了信息存储的地方，也代表了事实，可以作为企业决策的依据。
• 数据访问层 - 这一层主要用来获取数据库信息。
• 业务逻辑层 - 世界上一切行为都可以看作是业务逻辑，这一层主要是加工（分解和组合）信息。
• 用户界面层 - 用来显示给用户显示信息。

三层模型从概念上是抽象度极高的，抽象度高意味着在落地时候还需要做很多工作.

基本上，在三层模型里，对任意一层，可以有如下处理

• 将这一层根据需要拆解成n层
• 将这一层和其他层合并
• 这一层和其他层之间增加新的一层

我个人很感兴趣的一件事情：

• 三层架构模型能不能像魔方一样经过几次变换然后变成其他架构模型呢？

传统的DDD分层架构

从概念上来说, 传统的DDD4层模型可以由三层模型稍加改进得来.

• 用户接口层， 这层对应三层当中的用户界面层. 可以有两者解读
  • 广义上是指UI，API
  • 狭义上是指API
• 应用层，组合领域层和调用其他应用层。 这层可以看成是由业务逻辑层拆解而来。
• 领域层，这是整个系统的重点，也是兵家必争之地。领域层要确保在整个系统的复用性.这层可以看成是由业务逻辑层拆解而来。这层包括
  • 领域服务的定义
  • 领域对象的定义
  • 领域事件的发布
• 基础设施层，包括缓存，队列，网关，数据库，可以对应三层的数据层.

这里的特点是任何一层都可以访问基础设施层。 就好像一个组织里，大领导可以过问下层的工作细节，下层可以越级汇报给上层。

依赖倒置的DDD分层架构

相比于传统的DDD的分层，依赖倒置的分层一点点反直觉。
传统的DDD分层，层和层之间的箭头流向代表着

• 调用关系-RPC调用或者发布一个事件

但是依赖倒置的DDD分层的箭头带来的确实含义完全不一样的理解

• 绿色的箭头代表的不是调用关系，因为很明显技术设施层怎么可能调用用户接口层呢？这是最明显反直觉的一点。所以这里(A->B)的绿色箭头代表着，B比A要重要，A的任何改动不会影响B,B的变化会影响A.
• 黑色的箭头代表着正常的调用。
• 这幅图最大的问题在于一个箭头有两种完全不同的语义.

绿色思考帽

想象一个人在飞机上，有四个包裹分别为用户接口层，应用层，领域层，基础设施层，这个四个包裹的重量一样，但价值不一样。现在飞机动力不足了，我们要扔掉包裹，才能让飞机有动力继续飞行. 我们会怎么扔？

• 扔第一个包裹。扔掉基础设施层，因为落地之后，换一个基础设施层就好了
• 扔第二个包裹。扔掉用户接口层，相比于其他层，用户接口层没那么重要.
• 扔第三个包裹。扔掉应用层，相比于领域层，应用层没那么重要.

所以我们可以看到领域层是最重要，只要领域层在，一个业务的灵魂就在。正如我们听到的紧紧围绕在XX同志为代表的领导下，开发业务的时候同样如此，要紧密团结在领域层周围做事情.

DDD 五层架构

背景

一个人在公司里是员工，可以完成上级的任务，在家里就是父亲，可以教育子女. 如何用从代码层面描述这两种场景，而且符合开发者的心智模型？

• 张三 + 场景 (公司) -> 完成上级任务
• 张三 + 场景（家里）-> 教育子女

一个可行的的公式：谁(Who)什么时候(When)在什么地方(where)用什么方式(How)完成了某件事(What)？基本上这个公式可以描述很多场景的行为，这样能保证描述不具备歧义性。比如：我上午骑车去超市买了瓶可乐。

什么是五层架构？

五层架构也叫DCI(Data + Context + Interactive)架构，是2009年由James O. Coplien和Trygve Reenskaug共同提出.
DDD五层是对DDD四层的改进

• Context层 - 由四层的domain拆解而来
  • 负责将领域对象变成Role
• Domain层 - 由四层的domain拆解而来
  • object - 描述对象的关系
  • role - 用来给对象创建一个 role, 员工或父亲。 这个Role可能以后会带来歧义，因为一些权限验证框架里面也由Role这个概念.

什么时候应该用五层架构？

• 梳理完整个业务之后，如果一个实体在业务中有多个不同的称呼，这个时候就应当用五层架构模型，如果实体在业务中的称呼是唯一的，那们就四层模型就够了。可能有朋友要问了，如果用四层模型，现在业务实体的称呼只有一个，那将来实体要是有多个称呼可怎么办呢？那就演化到五层。

DDD 六层架构

六边形架构

整洁架构-洋葱模型