显卡|微服务与领域驱动设计，架构实践总结( 二 ) 游戏主机|机箱|雷神|数码

站在业务角度，进行模块化拆分和管理，结合持续集成的组件，通常可以轻松地应对各种复杂的业务场景，但是不存在真正意义上一劳永逸的手段，业务变化带来的各种问题总会无脑推动开发去寻找更合理的解决方案；

在一次完整的电商交易场景中，实际上真正涉及到的微服务远不止图中的几个，在Trade服务中交织关联多个其他服务，在MVC的分层管理下，初期并不会存在较大风险，但是业务一旦经过多版升级改造之后，并且还存在版本兼容的要求，会给人一种极度混乱和不踏实的感觉；
如果团队成员的综合能力较高，并且版本有充足的时间去设计和优化，这种问题是可以妥善解决的，如果出现时间紧任务重的情况，随之而来的压力会持续在开发和测试之间来回横跳；
解决过相关业务场景的研发都知道，重构加持续集成能力，结合严谨的测试，可以应对业务的不断变化；但是在版本兼容的过程中，依然会导致工程中的代码膨胀到飞起，特别是出现中场换人的情况，都会让接手的人员在被埋和离开中，产生一次剧烈的心态挣扎。
3、问题分析在MVC的架构模式中，工程通常会进行如下的分层管理：控制层、服务层、持久层、存储层；服务层在特定复杂的场景中会做细化拆分，比如第三方对接、常用中间件的二次封装：

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

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

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

关于子域的划分也是参考业务属性，可以把核心域理解为最关键的业务场景，并且需要资源倾斜以应对其不断地发展；支撑域可以理解为相对稳定的业务；通用域偏向系统架构层面的公共能力；通过对领域的拆分实现业务分治，这与微服务的拆分思想相符合，两种模式在业务角度是比较统一的；