架构五视图与DDD

架构五视图、DDD……，方法论越来越多，他们之间是什么关系？能够融合使用么？中间需要注意哪些问题，分享一下我的理解

一、为什么DDD和架构五视图可以结合使用？

架构五视图告诉大家可以从5个视角（视图）来思考架构设计，每个视图关注的点如下：

架构设计的起点是对业务的分析，通过建立用例模型\界面原型共识对业务方案的理解，通过对用例、流程的业务分析进行子系统划分，对问题进行第一次分解，这就是所谓的逻辑架构；

业务分析逐步深化，我们把注意力聚焦在业务对象的抽离上，通过分析用例，名词识别，识别出业务对象及其属性。选取部分需要持久化的对象，建立数据对象及数据对象关系。最后结合设计目标与设计范式，做对应的数据库设计，这就是数据架构；

业务模型建立后，我们开始做架构映射，把业务对象映射成类，形成初步的类图，业务逻辑部分的设计大体成型。接下来我们引入分层架构来精炼我们的模型(比如经典的MVC架构)，完成一般意义上的详细设计，这就是开发架构；

运行架构、物理架构略。

从上面的分析可以看出，五视图的前三个视图，基本覆盖了传统的架构设计的几个关键步骤：业务分析 – 数据库设计 – 详细设计。通过逻辑架构的纵向划分（子系统\模块划分）实现问题的初步分解，通过开发架构的横向划分（分层）实现隔离变化的目的，这两次划分保证“高内聚、低耦合”的设计原则最低限度的落地。

那么有没有更好的方式，通过一系列设计步骤，直接得到更“高内聚、低耦合”的设计？DDD说”有”，当然前提是这是个“高业务复杂度场景”。

额外的效果需要额外的动作，DDD是怎么做到的呢？有如下几方面。

• DDD大幅提升了对业务分析（DDD称为领域建模）的重视度。传统的设计虽然也强调对业务的分析，但大部分开发并不重视，认为我只需要“理解”，不需要“动手”，业务建模变成简单的画画用例、流程图。DDD强调，高业务复杂度场景下，最重要的是需要统一语言，通过和业务专家一起协作，迭代式的探索和发现模型，最大化的减少信息传递的扭曲、遗失现象，从而减少设计的频繁变化。
• 纵向划分上，不同于传统的设计划分（子系统\模块划分），DDD提出问题空间-子域、解空间-限界上下文的概念。这样做带来了两个好处，一是呼应对业务的重视程度，促进开发思路转变，聚焦关键问题（核心域），而不是一脑袋扎进代码方案；二是限界上下文的提出使得纵向划分更细、逻辑性更强(可以对比一下子系统\模块的划分原则和限界上下文的划分原则)。 还没完，DDD还创造性的把纵向划分向下延伸了一个层次。纵向划分，传统的设计是 应用 – 子系统\模块 – 对象，而DDD的设计是应用-限界上下文-聚合\领域服务-对象\值对象。通过聚合\领域服务概念的提出，DDD在纵向划分上粒度更细，对“高内聚、低耦合”的支撑更强。甚至可以说，DDD是第一个可操作，有逻辑的”高内聚、低耦合”的落地方案。

• 横向划分上，DDD认为，在高业务复杂度场景中，业务本质变化速率是最低的，这一层需要单独被抽离，称为领域层；业务方案变化速率其次，称为应用层；UI层和传统观念一样，单独一层；基础设施(数据库、框架)本质上和业务无关，很多场景有独立升级的诉求（比如用业界最新的框架），单独抽离出来称为基础设施层。这样，在横向划分上，DDD从复杂业务的本质特点出发，划分成了4层。

二、架构五视图融合DDD

我们可以借助DDD的思想进行架构五视图的设计，其对应如下（红色字体为DDD涉及概念）：

推荐几个业界最佳实践

服务风暴模式：其特点是借助业务服务(问题空间概念)来识别子域，结合服务契约(业务服务在解空间的映射)完成限界上下文的识别，完成领域建模后结合菱形架构完成代码的映射。服务风暴模式重点覆盖了逻辑架构和数据架构两部分，数据库设计并未重点强调，可以认为随着”精炼设计模型”同步产生

三、常见问题

1、产品人员共创意愿和共创投入程度低。具体表现在：产品人员认为开发只用负责技术实现，问业务谈价值就觉得你越界了。

思考：公司推系统架构师也是为了打破这种惯性，系统架构师必须做系统分析，DDD是一个很好的思路

2、DDD原始理论中的领域划分和限界上下文是对架构五视图的有益补充，其它内容作用不大；

思考：DDD最重要的几大概念：①统一语言②战略设计（子域与上下文）③新的分层架构 ④战术设计（聚合等），很多组只用了相对简单的②、③，①作为基础部分需要工作流程改变（与业务专家一起工作），④门槛高，需要理解各个概念(定义，想解决的问题，为什么可以解决)。最理想的情况是建立可量化的设计指标体系，把DDD指导下的设计和非DDD思路做的设计能拉在一起比较，用效果来证明价值。其次就是可以定性的对比优劣。

3、业务复杂度高时选择DDD，不宜为了做而做

思考：同意

4、DDD分析过程是自成体系的一个套路，和架构五视图结合时，两个方法论会有重复，前后逻辑关联性会差一些，内容会有突然跳转的情况出现

思考：可以尝试按照上图来做，总(业务背景 – 设计目标 – 逻辑架构)，分（以BC为单位进行数据架构、开发架构、运行架构、物理架构），当然也可以按照产品特点做统一的运行架构和物理架构设计