MDD 建模驱动设计
搭建中台缺少方法论或者实践？
系统开发者最终的实现与产品设计常常出现偏差？
系统开发者带着产品在跑设计？
每个开发者对业务理解不同，实现不同，在人员交替的时候代码逻辑分支太多？
项目干系人沟通缺少共同的语义，理解不一致？
那期待您共同参与到MDD架构实践
**
一 尼式三原则
**
- 唯一原则
所有业务围绕核心业务展开，并且核心业务是唯一的。如果核心业务不唯一，业务所在的系统需要进行拆分，直至唯一，拆分后的每个子系统存在仅存在唯一的核心业务流。
- 隔断原则
核心业务代码的组成单位是模块。隔断性表现在垂直隔断和水平隔断。
一核心业务主要基于模块而非其他业务或者更基础的业务单元代码；
二模块是业务隔断的，模块的边界与业务划分不重合甚至是业务近似无关的，如果在概念上可以抽象成业务无关名词，其实更合适。
- 串连原则
模块之间唯一的关系是抽象模型。隔断原则使业务代码依赖的模块散落乃至没有业务意义，如何串联呢？或者如何使得模块的编排和组合实现核心的业务逻辑呢，答案就是抽象模型。
通过场景串联使得模块成为抽象模型的模块。
**
二 3V 模型
**
3V 模型
3V 模型描述了三个原则在每个阶段的适用场景。
第一步 系统整体建设阶段，使用核心原则抽取出业务核心，初步划分系统。拆分出核心系统。核心系统对应的核心业务流进行抽象，形成多个独立的抽象模块，结合场景进行模块的场景串连，主要串连主业务场景，考虑周边场景的合理性最终形成抽象模型。该阶段的反弹，最终的抽象模型会反馈至模块，模块需要进一步拆分或者聚合。使用反弹阶段的模块产物来组织周边系统的建设。这个阶段是系统的递归分析；
第二步 系统内部建设阶段，使用核心原则抽取出关键的领域核心，在第一阶段生成的模块产物需要和领域进行关联，这种关联性是领域中模型基本属性的关联，非业务性强关联。该阶段的底部及使用关联了基本属性的模型进行领域模型生命周期的串连。这个阶段是子系统的递归实现。
第三步 功能完成建设阶段，以第二阶段生成的模块产物为基本代码组织核心的功能，需要补充逐渐增强的业务逻辑代码，主要是在粘合模块产物而非重新定义逻辑。检验的标准是可以串连完整的业务功能。这个阶段是功能的递归实现。
三个步骤中落实“尼式三原则“，在两个不同维度（系统间和系统内）进行递归式分析和实现，最终收敛于模块，理想的状态就是业务逻辑的模块化，这与隔离原则契合，使得整个系统业务逻辑模块化取代模块代码是业务的，零散的。
九点图
九点图描述了层级依赖的关系，依赖的关系在3V模型中有已体现。模型层是抽象模型和模型模块的整合层。领域层是与DDD实践时的层次结构。业务层也是一般的应用层概念。
隔断原则维护了模块的高内聚，模块需满足开闭原则，保持对扩展的开放；串连原则保证了低耦合，使得业务模型和抽象模型是唯一映射的关系，而非模块或者具体的业务代码，这也是唯一原则的另一层面体现。
非核心业务代码可以满足隔断原则，也可以不满足。从核心业务到非核心业务，从核心模块到非核心模块可能存在隔离性的衰减。
再总结一下唯一原则，一个系统对应一个核心业务流，也对应一个完整的抽象模型。以上原则可以做到在围绕核心业务，做到似断非断，在该断的时候断，不该断的时候相连。
**
三 职能划分
**
抽象模型是开发与产品之间的沟通语言，也限定了项目干系人沟通的共同语义。通过抽象模型保持项目组内的理解的统一性，在达成一致后，该层是最稳定的。模型模块是不能职能的开发人员的沟通语言和工作关联。业务逻辑基于模块的组合编排，灵活性最高。
当业务需求变化时，
| 业务需求变化影响范围 | 参与人员 |
|---|---|
| 影响到业务逻辑变化 | 产品+具体实现人员 |
| 影响到模型模块 | +技术负责 |
| 影响到抽象模型时 | +架构师 |
当需求变化影响到抽象模型时需要架构师的配合，如变化范围较大，需要重新规划版本。项目的干系人职能约定在以上范围内，层层保证业务设计与技术实现的匹配。
**
四 MDD 与 DDD 的关系与不同
**
相同：MDD 是DDD 设计方法的延申，特别是DCI 架构的接近，M是C的替代和演进。领域模型是领域驱动设计的核心，而在DMD中，Modeling 是设计的核心。这种方法解决了贫血模型和富血模型的冲突，同时支持DDD的三分层结构和传统的四层代码分层结构。
不同：MDD 提供原则和方法论的描述，可以与DDD 的相融相生，也可以指导传统的架构设计方法。
**
五 交流
**
如果实践成功，欢迎交流；如果发现掣肘，欢迎拍砖。