微服务与领域驱动设计，架构实践总结( 二 ) _交易

【微服务与领域驱动设计，架构实践总结】如果团队成员的综合能力较高，并且版本有充足的时间去设计和优化，这种问题是可以妥善解决的，如果出现时间紧任务重的情况，随之而来的压力会持续在开发和测试之间来回横跳；
解决过相关业务场景的研发都知道，重构加持续集成能力，结合严谨的测试，可以应对业务的不断变化；但是在版本兼容的过程中，依然会导致工程中的代码膨胀到飞起，特别是出现中场换人的情况，都会让接手的人员在被埋和离开中，产生一次剧烈的心态挣扎。
3、问题分析在MVC的架构模式中，工程通常会进行如下的分层管理：控制层、服务层、持久层、存储层；服务层在特定复杂的场景中会做细化拆分，比如第三方对接、常用中间件的二次封装：

对于在复杂业务线上争渡的选手来说，对Mvc分层模式的缺陷是深有体会的， Service层聚焦大量复杂的逻辑，通常核心业务块中总会存在几个代码过千行的实现逻辑，不管用什么思路和模式去拆分封装，都很难解决该层不断扩展带来的膨胀问题。
4、面向过程在MVC分层中，过程式的代码极其明显，通常以数据库表和关系为基础，映射构建相关实体对象，这些实体对象并没有具体的行为和逻辑，只是作为数据和结构的载体：

从面向对象中类的定义去看：属性和行为；而在MVC模式中，绝大多数实体都只是作为数据的入参出参的结构定义，可以理解为数据容器，在MVC的各层之间不断搬运和加工。
三、领域驱动设计相比MVC的分层设计，领域驱动设计(Domain-Driven-Design简称DDD)对于复杂业务系统的实现，提出了更加合理的解决方案， DDD模式中涉及大量专业术语和抽象概念，可以参考EricEvans的相关书籍，本文只描述实践中的核心概念。
1、分离模式DDD模型在分层设计上，划分出核心的四层：接入层、应用层、领域层、基础设施层；注意这里只是单纯站在服务端的常规架构角度去看，很明显分离MVC模式中的服务实现层的逻辑：

其中领域层是关键所在，用来封装复杂的业务，对应用层提供业务管理的核心支撑；整个模型也更具备纵向思维，有效地缓解单层复杂度过高的现象；单从模型设计上看，在工程中基于该分层去管理代码包，也可以使每层的设计更加清晰和独立。
2、设计思想领域驱动设计并不是简单的分层管理模型，涉及诸多抽象逻辑与专业术语，例如：领域、界限上下文、实体、聚合、值对象等等；
2.1 领域
领域可以理解为业务场景中需要解决的问题合集，是具有范围和边界的约束；领域可以拆分为多个子域，通常描述为：核心域、支撑域、通用域：

关于子域的划分也是参考业务属性，可以把核心域理解为最关键的业务场景，并且需要资源倾斜以应对其不断地发展；支撑域可以理解为相对稳定的业务；通用域偏向系统架构层面的公共能力；通过对领域的拆分实现业务分治，这与微服务的拆分思想相符合，两种模式在业务角度是比较统一的；
2.2 界限上下文
DDD中最晦涩难懂的一个抽象概念，特定模型的限界应用，不过可以借用原文的比喻会意一下：细胞之所以能够存在，是因为细胞膜限定了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜：

界限上下文的定义涉及粒度的思想，即每个粒度要具备独立性；如上图仓储业务，可以将服务部署与仓储子域、仓储上下文做成一一对应的关系，或者在仓储子域中分别定义：仓库和货架两个上下文；这里具有极大的灵活性，没有真正意义上的标准可以参考。
2.3 映射关系
做好界限上下文的划分，理清各个上下文之间的关系，明确业务场景中的依赖顺序，这样可以更好地推动开发流程的落地；对于上下文的关系描述也远不止图中的这些，还有共享内核、合作等等: