dci 四色模型结合

by 夏泽民 Feb 26, 2020

https://www.jdon.com/dci.html
DCI是对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为三者简称， DCI是一种特别关注行为的模式(可以对应GoF行为模式)，而MVC模式是一种结构性模式，DCI可以使用演员场景表演来解释，某个实体在某个场景中扮演包公，实施包公升堂行为；典型事例是银行帐户转帐，转帐这个行为按照DDD很难划分到帐号对象中，它是跨两个帐号实例之间的行为，我们可以看成是帐号这个实体(PPT，见四色原型)在转帐这个场景，实施了钞票划转行为，这种新的角度更加贴近需求和自然，结合四色原型 DDD和DCI可以一步到位将需求更快地分解落实为可运行的代码，是国际上软件领域的一场革命。

DDD DCI和领域事件
DDD是领域驱动设计(Domain-Driven Design )的简称，DDD是一种分析设计建模方法，它倡导统一语言，提出了实体和值对象以及聚合根等概念，借助DDD我们能够在结构理清需求中领域模型。DDD专题。

 DCI: Data数据模型, Context上下文或场景, Interactions交互行为是一种新的编程范式，由MVC发明人Trygve Reenskaug提出。 DCI架构是什么？ 

 DCI的关键是:

 1. 要让核心模型非常瘦.

 2. 逻辑或行为应该放在角色这个类中

 Event Sourcing是由Martin Fowler提出，是将业务领域精髓（尤其是最复杂的）与技术平台的复杂性实现脱钩的天作之合。为什么要用Event Sourcing?或 Domain Events – 救世主

https://www.jdon.com/jdonframework/dci.html
https://www.jdon.com/37976

DCI是数据Data 场景Context 交互Interactions的简称，DCI是一种特别关注行为的模式(可以对应GoF行为模式)，而MVC模式是一种结构性模式，MVC模式由于结构化，而可能忽视了行为事件。我在javascript事件总线一文中也谈过这个问题，Javascript这种函数式functional语言能够帮助我们更加注重行为事件。

DCI可以说是函数式functional编程比如Scala带来的一个理念，The DCI Architecture: A New Vision of Object-Oriented Programming一文(以下简称DCI Architecture)从OO思想根源来深入解剖DCI对传统面向对象的颠覆。

DCI可以使用Scala的traits方便实现，Java中可以使用AOP中的Mixin来实现，也是一种面向组合编程，这点DDD领域驱动框架Qi4j做得比较好。忘记Scala，Qi4J是下一个 Java?

DCI Architecture认为传统MVC只是表达了用户界面交互中的结构，而没有表达交互行为：

它以字处理器中拼音检查为例，拼音检查这个行为功能放在哪里？是dictionary 还是一个全局的拼音检查器呢？无论放在哪个对象内部，都显得和这个对象内聚性不高，由此带来多个调用拼音检查行为对象之间的协作耦合，在DDD中，好像认为这种情况是使用Service服务来实现；在SOA看来，拼音检查属于一种规则，可由规则引擎实现，服务整合流程和规则。

DCI架构则不同于DDD这种有些折扣的处理方法，而是思路复位，重新考虑架构，从对象的数据object Data, 对象之间的协作the Collaborations between objects, 和表达需求用例中操作者角色之间的交互这三个出发点来考虑。个人感觉又把桥模式演习了一遍，其实Qi4j代表的Composer组合模式或Mixin不就是在运行时，把对象以前没有的行为给注射进入，达到根据运行需求搭桥组合的目的。

DCI Architecture也总结了算法和对象的关系，这点在Jdon也曾经热烈讨论过，按照OO思想，应该把算法切分塞进对象中，Eric在DDD一书中也阐述过，不要因为大量算法实现(属于“做什么”)，而忽视了“是什么”，我也在函数式编程functional programming的特点中进行了复述。

当然，算法派还是相当不甘心的，这次总算凭借Scala等函数式语言进行了一次“反扑”，哈哈，DCI Architecture从交互行为入手，提出了如果算法横跨多个对象，不能被切割怎么办呢？这个问题表面上好像提得很好，那么过去我们是怎么解决呢？在SOA中，这种算法被表达为流程工作流或规则，通过服务来进行聚合(也是一种Composer)，所以，是不是可以认为DCI架构是SOA架构的另外一个翻版？

DCI Architecture认为：数据模型data model, 角色模型role model, 协作交互模型collaboration model(算法属于协作交互模型)应该是程序语言核心关心点，应该在语言层次关注这三个方面。大概这是和SOA区别所在，传统观点：语言一般低于架构，当然，语言和架构遵循水涨船高准则。

DCI Architecture是怎么认为数据模型呢？它认为模型应该是哑的，也就是静止的，所以才叫数据性对象。这个我应该不能认同，如果是这样，数据模型实际上就是失血贫血模式了，只有setter/getter方法的数据模型。

DCI Architecture那么认为角色模式是什么呢？感觉其说得不是很明白，因为它用代码案例来表达，这种从抽象直接跳到具化的思维方式我不是很喜欢，感觉逻辑上无法前后一致，因为对具体实例的逻辑解释有很多。

在两个账户之间转账，DCI Architecture认为在我们一般人脑海中，转账这个模式是独立于账户的一个模型，它应该属于一种交互interaction模型。由此引入了roles角色模型，正如对象表达它是什么，而角色表达的是有关对象做的一系列行为结合。

角色模型之所以对于我们如此陌生，因为我们以前的OO思维是来自OO程序，而以前的所谓OO程序包括Java/C都缺乏对角色模型的支持。角色介入混合的交互模型其实不是新概念，过去称为algorithms算法(和我们通常数学算法概念有些区别)。

当然我们可以将这些交互行为按照对象边界划分办法细分到一个个对象中去，不幸的是，对象边界本身划分实际上意味着它已经代表一些东西，比如领域知识。目前很少有这方面的建模知识：将算法逐步精化细分到正好匹配数据模型的粒度(然后就可以装到数据模型中，成为其方法了)。如果算法不能精化细分，那么我们就把算法整个装到一个对象中去，这样可能将算法中涉及到其他对象和当前对象耦合，比如上面转账这个算法，如果整合到账户Account模型中，因为转账涉及到其他账户和money对象，那么就将因为行为操作带来的耦合带到当前账户对象中了；当然，如果算法可以精化细分，那么我们把它切分到几个部分，封装成几个对象的方法，这些方法都是无法表达算法算法高内聚性的琐碎小方法，可谓面目全非，实际上，我们过去就是这么干的。

角色提供了和用户相关的自然的边界，以转账为例子，我们实际谈论的是钞票转移，以及源账户和目标账户的角色，算法(用例角色行为集合)应该是这样：

1.账户拥有人选择从一个账户到另外一个账户的钞票转移。

2.系统显示有效账户

3.用户选择源账户

4.系统显示存在的有效账户

5.账户拥有人选择目标账户。

6.系统需要数额

7.账户拥有人输入数额

8.钞票转移账户进行中(确认金额修改账户等操作)

设计者的工作就是把这个用例转化为类似交易的算法，如下：

1.源账户开始交易事务

2.源账户确认余额可用

3.源账户减少其帐目

4.源账户请求目标账户增加其帐目

5.源账户请求目标账户更新其日志log

6.源账户结束交易事务

7.源账户显示给账户拥有人转账成功。

代码如下：

template
class TransferMoneySourceAccount: public MoneySource
{
private:
ConcreteDerived *const self() {
return static_cast<ConcreteDerived*>(this);
}
void transferTo(Currency amount) {
// This code is reviewable and
// meaningfully testable with stubs!
beginTransaction();
if (self()->availableBalance() < amount) {
endTransaction();
throw InsufficientFunds();
} else {
self()->decreaseBalance(amount);
recipient()->increaseBalance (amount);
self()->updateLog("Transfer Out", DateTime(),
amount);
recipient()->updateLog("Transfer In",
DateTime(), amount);
}
gui->displayScreen(SUCCESS_DEPOSIT_SCREEN);
endTransaction();
}

以上几乎涵盖了用例的所有需求，而且易懂，能够真正表达用户需求心理真正想要的。这称为methodful role

角色role体现了一种通用抽象的算法，他们没有血肉，并不能真正做任何事情。在某些时候这一切归结为那些表现领域模型的对象。数据模型表达的“是什么 what-the-system-is”，那么有一个bank和子对象集合account, 而算法表达的“做什么what-the-system-does”则是在两个账户之间转移钞票。

到这里，我有一个疑惑，我们倡导DSL，是希望把“是什么”和“怎么做”分离，这里“做什么”和“怎么做”是不同含义吗？我过去认为算法属于怎么做，属于实现部分，但DCI Architecture却认为它属于“做什么”部分，看来对算法定义不同，算法如果是数学算法规则公式，应该属于“怎么做”(使用算法实现)，如果算法属于用户角色的行为，那倒是属于“做什么”问题，但是在DDD中，我们认为“做什么”应该属于“是什么”的一部分，DCI Architecture将其分离。

为什么分离？因为“做什么”和具体用户角色有关，通俗讲，可以看成是人和物相互交互的结果，是一种用例场景，人和物可能有各种交互场景，这就成为Context，是 Use Case scenario的Context。

看来，DCI Architecture是将“是什么”和“做什么”进行分离，然后根据需求在不同场景动态结合，还是桥模式的味道

DCI Architecture一文下半部就是如何实现它的架构思想，是关于“怎么做”的了，建议传统语言在编译时，就将角色的行为或算法混合Mixin到数据模型类中，这是典型的AOP思想。

下图就是DCI Architecture架构把MVC模式肢解，将C和V用对应的Context来替代。

这样，DCI架构真正含义可以归结如下：

1.数据data：是领域对象中代表领域类概念的那部分。

2.场景context：根据运行时即时调用，将活的对象实例带到符合用例需求的场景中

3.交互interactions, 描述需求用户心目中角色的活动算法。

就象上图中，把场景Context看成是一张表，角色行为作为横行加入，而数据模型作为纵行加入。

具体实现，可以在运行时，通过动态反射将业务逻辑行为注射到领域模型对象中，动态语言比较方便，C++ 和 C#使用pre-load预加载，Scala使用hybrid 混合，DCI Architecture一文没有提到AOP，可以使用AOP中静态weave方式混合，现在javassit等动态代理框架都支持静态weave，包括AspectJ/Spring，在编译时就将业务行为注射到模型中。

DCI Architecture一文接下来详细介绍了Scala中的traits 是如何实现这一注射的。traits 能够让方法在程序运行时注射到一个对象实例中：

trait TransferMoneySourceAccount extends SourceAccount {
this: Account =>

// This code is reviewable and testable!
def transferTo(amount: Currency) {
beginTransaction()
if (availableBalance < amount) {
. . . .
}
}

. . . .
//通过下面特别的对象创建方式生成符合用例的源账户和目标账户
val source = new SavingsAccount with TransferMoneySourceAccount
val destination = new CheckingAccount with TransferMoneyDestinationAccount

个人思考：在代码编译时混合注射已经不是新鲜方式，Spring2.0开始已经可以做到，Scala以一种更易懂代码方式实现，现在需要思考：我们这样做的目的是什么？就是实现Context场景混合，说白了，就是到用户现场烧菜。

条条大路通罗马，为实现这一目标，我们可以采取另外一种方式，用户现场的本质是什么？用户现场为什么是活的，Context为什么是活的？因为用户的动作，动作引发事件，因此，事件模式可能是Context的本质。

如果是这样，只要我们遵循事件编程模型如EDA架构，也许也能实现DCI架构？比如通过Domain Events来激活角色行为：

账户拥有人操作自己的账户(领域模型)，这个账户领域模型发出事件，驱动目标账户进行帐目更新，最后返回给账户拥有人，转账成功。

https://github.com/banq/jdonframework
“阅读次数”到底应不应该属于帖子这个对象的属性，其实这个问题存在很多案例中，“阅读次数”可以说不是帖子的固有属性，帖子这个对象离开“阅读次数”这个属性不是不能存在，探究“阅读次数”这个属性和固有属性比如帖子的名称等是有区别的，属于一种场景属性，也就是说只有在阅读这个场景下才会发生的属性。

DCI架构本质：DCI: 对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为，我们知道，对象有数据属性和方法行为，以前我们是封装在一个对象中，为什么要封装在一个对象中？因为这个对象在某个需求用例场景中被使用时需要这些属性和方法行为，注意了，这里面有一个关键点，就是对象被使用，以前我们进行面向对象设计，是遵循一种静态原则，因为这个对象被使用需要这些属性和行为，所以，我们在编码时将这些属性和行为写在这个类中。

这个逻辑过程是不对的，那是因为过去程序语言平台落后，导致了我们这种思维逻辑，现在是的思维逻辑是：对象被使用时需要的属性和行为不必一定要在编写代码时写入，而是在运行时再注入或MiXIN混合进去。

这就是DCI架构的本质。

我们还是以“阅读次数”这个案例分析，在以Jive Jdon案例说明对象职责和SOLID原则应用一文我们讨论焦点集中在“阅读次数”到底应不应该属于帖子这个对象，其实这个角度有问题了，如果按照DCI架构和对象角色职责这个架构来考虑，应该这样：

我们除去具体事物如用户和帖子，而是从角色来分析这个场景，就像上贴中存在“分配者”和“被分配者”一样，这里存在两个角色“阅读者”和“被阅读者”，而场景Context是和“阅读者”有关的一个对象，那么一个帖子被阅读的建模描述如下：

第一步：根据用户创建一个阅读场景对象：

ReadContext readcontext = RootContext.create(userId)

第二步：由阅读场景对象来执行交互行为阅读：

readcontext.view(readed);

其中readed被阅读者就是帖子。

所以，按照DCI架构来说，阅读这个行为应该属于Context场景这个行为，只有在这个场景下才会发生阅读这个行为。

如果不按照DCI架构来分析，我们会倾向把阅读这个行为放到“帖子”这个对象中，有人担心，以后再有“顶”这个行为，那么顶的结果数据也要放到“帖子”这个对象中，这里有一个误区，“帖子”不是一个类，不是说所有场景属性结果都放如帖子这个一个类中，帖子只是一个对象群中根实体，我们可以根据不同场景创建不同实体类或值对象，都从属于“帖子”这个根实体，组成一个边界和子领域。

当然，如果有Qi4j或AOP的Mixin来支持，我们也可以使用楼上这种DCI架构方式。

但是个人认为，上面AssignmentsMixin类实际是和业务无关的器具技术类，如果语言本身提供AssignmentsMixin这个混合机制，就不再需要了。

另外，DCI架构中对于我们普通的POJO技术，也就是没有Mixin支持的环境中，最大的借鉴就是引入Context这个场景对象，D和I以前都有，就是对象的数据和方法，通过Context这个对象引入，使的我们的软件更加贴近需求分析中用例场景，四色原型可以说是DCI架构的前言。

Context这个对象其实和角色动作职责有关，如果你不是管理者，你就不可能进入管理这个场景，角色是场景的前置条件，交互动作是场景的必然结果，很符合DBC设计原则。

这应该是面向对象设计领域新的革命思维

https://www.jdon.com/38266#23127442
https://www.jdon.com/design.htm
https://www.jdon.com/49772

Category architect