从DDD DSL DCI 说起

软件行业隔一段时间大家就喜欢造一些名词，比如xx化，服务化，动态化，配置化等，你可以头脑风暴下，你可以搞出多少“化”来。比如最近火的都不是数据化，智能化了，而是什么“数智化”了，你说神奇不。

当然并不是所有的名词都向着贬义的方向演进，很多名词可以便于我们去理解一些新的概念，或是用不同的角度看待一个问题或者场景。相信我们总会有一些东西，感觉介于几个概念之间，但是有拿不准他应该属于哪里，比如就有今天讲的这几个。

DDD （Domain-Driven Design）和 DSL（Domain-Specific Language）、DCI（Data，Context， Interactive）的关系，很多人心存疑问。

DDD 概念作为一种软件开发的指导思想，为软件开发带来的好处主要有以下几点：

第一，最大好处就是所有参与者围绕一个统一的领域模型工作，传统的分析模型和设计模型不再割裂，不管是做设计、做分析还是写代码、写文档，脑海中所构建的画面都是一致的。

第二，DDD 是一个软件开发过程，它显式地把领域和设计放到了软件开发的核心，软件人员和业务人员受到同样的重视，他们合作来构建领域模型，使得软件的交付质量更高且维护成本更低；

第三，DDD 提出的分层架构，有效分离了业务复杂度和技术复杂度，凸显了领域模型，使得领域层的代码和领域模型保持高度一致；

第四，统一语言非常重要，每个概念在各自的上下文中是清晰的无歧义的，同时要控制领域模型的复杂度，于是 DDD 在战略上提出了分离子域（问题域空间）和拆分 BC（解决方案空间）的模式，BC 间通过 Context Mapping 来集成；

第五，DDD 在战术层面提出了很多模式（聚合、实体、值对象、服务、工厂、仓储），对领域模型中的元素进行了分类，并给出了每类元素在领域模型中的职责和特征，降低了领域模型的构建成本。

作为相近概念的DDD 和 DSL、DCI 之间存在一定的关联性。

DDD 和 DSL 的融合有三点，面向领域、模型的组装方式以及分层架构演进。DSL 可以看作是在领域模型之上的一层外壳，可以显著增强领域模型的能力。

主要有两个：

一是提升了开发人员的生产力，二是增进了开发人员与领域专家的沟通。

DSL 可以用于描述流程契约，友好且学习成本也很低（当然是在设计好的角度来说，设计的差的话，徒增压力）。

对于 DSL，需要自己实现一个解析器将 DSL 文法解析成语法树，再根据语法树生成语义模型。语义模型可以看作领域模型（严格的讲语义模型是领域模型的子集），外部 DSL 就是对领域模型的一种组装方式。

对于 DSL设计建议大家尽量参考业界主流解决方案，千万不要轻易尝鲜变成小白鼠。

DCI 可以助力 DDD 战术设计，如：

显式地对 ROLE 建模，解决了贫血模型与充血模型之争；

明确一个聚合可以支持哪些 ROLE、一个 ROLE 可以由哪些聚合扮演以及一个场景下哪些聚合要扮演哪些角色；

当 Aggregate 内部实体行为比较多时可以嵌套使用 DCI 来拆分和组合。

其次，DCI 助力 DDD 代码落地，如：

对象就是 Data，Client 为 Context，对象在 Client 中的行为就是 ROLE；

根据正交设计原则得到小类（素材库），根据多重继承或依赖注入来组合素材，不管是行为类还是数据类，都按 ROLE 的方式来组合，对像仅仅组合 ROLE 并注入依赖；

当然我也不建议团队过度尝试DDD的战术层面的事情，做好了如虎添翼，做不好自断手脚，早晚重构。

类作为一种模块化手段，遵循高内聚，低耦合的原则，让软件易于应对变化。

对象作为一种领域对象的直接映射，解决了过多的类带来的可理解性问题，让领域可以指导设计，设计真正反映领域。领域对象需要真正意义上的生命周期管理。

某种程度上DCI 对一些开发人员的影响可能比 DDD 和 DSL 还大，因为开发人员每天都在不断倒腾代码，想让代码的组合性更强，以便快速应对需求的变化。

其实不理解这些名词也不用着急，技术行业日新月异，技术名词不断更迭，很多时候换汤不换药，换了面子里子还是一样的。

我就不信了，写好代码还能跑得出“面向对象思想”这六个字的手掌心？

写代码没那么多修饰和装饰，主要体现的还是最朴素的道理，比如：