DCI: 与领域驱动设计,四色建模的关系

接上篇: <<DCI: 代码的可理解性>>

与领域驱动设计的关系

Domain Driven Design是一种分析和设计方法, 它的目的也是使软件更简单更稳定更易于理解. 但它的出发点或角度是分离业务和技术细节. 业务相对技术实现细节来说是更稳定的, 也更贴近问题域.

DDD实际上有两部分的内容, 领域模型和如何建造领域模型. 但有趣的是事实上DDD对最终的领域模型看起来是什么样子并没有过多刻画, 只有Ubiquitous Language, 技术实现细节无关, Bounded Context等一些基本的属性. 那些构造块比如Entity, Value Object, Repository, Domain Service等既不必要也不充分. 难道不用DDD就不需要区分Entity和Value Object了吗? 难道用来Repository, Domain Service就是在DDD了吗?

DDD强调更多的是过程相关的实践, 比如与领域专家的合作,通过对话中的冲突矛盾之处来捕捉缺失的概念, 以及最重要的战略性设计: Distill Core Domain, Bounded Context, Context Mapping等.

DCI则正好相反: 它刻画了最终的领域模型是什么样子, 包含哪些元素, 而对软件开发过程保持中立.

因此可以说DDD与DCI是正交的, 可以结合使用. 我们可以用DCI来刻画最终的领域模型, 而用DDD推荐的实践来捕捉Data, Role, Interaction, Context等领域概念

（李彦辉说DDD书里的Building Blocks其实是一种参考实现, 比如Aggregate Root等概念. 因此也可以把DCI甚至下面的四色建模也都看成DDD的一种实现）

 

与四色建模的关系

四色建模也是一种分析和设计方法, 它的主要目的是确保最终开发出来的软件能支撑业务的运营. 客观上它也使模型更容易理解, 而它的出发点是业务的可追溯性. 角度是审计的角度. 前面我们说过电影和小说是可被人普遍所理解的. 事实上还有另外一件事也是有标准模型, 可被受过训练的人所理解的, 就是财务和审计. 换句话说, 如果我按照财务审计的要求来为业务建模, 那也是可以被普遍理解的.

而从不同的角度出发, 最终的结果却有重叠之处. 四色里的PartyPlaceThing可以看作DCI里的Data, 而Role甚至可以直接映射到DCI里的Role. 而Moment-interval和Interaction也有相似之处, 差别在于侧重点的不同. 总体来说, 四色建模还是侧重于系统的静态结构, 系统的状态, 而DCI则把交互作为一等公民.

(对四色建模的理解来自徐昊，比如这篇文章http://blog.vincentx.info/2011/12/on-moment-interval. 四色建模也偏重于结果, 对于建模过程, 徐昊还发展了一种尚未命名的方法来捕捉缺失的模型和去除冗余的模型, 核心是Data Flow)