DCI架构是什么？

摘自http://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 对传统面向对象的颠覆。

以字处理器中拼音检查为例，拼音检查这个行为功能放在哪里？是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

 ConcreteAccountType>
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来激活角色行为：

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