- 浏览: 305787 次
- 性别:
- 来自: 长沙
文章分类
最新评论
-
完善自我:
支持一下!
揭秘IT人才特点:中美印日四国程序员比较 -
悲剧了:
好文,看玩thinking in java的提到的异常处理,看 ...
高效的Java异常处理框架(转) -
yin_bp:
开源框架bbossgroups页支持组件异步方法调用哦,详情请 ...
Spring 3中异步方法调用 -
flyjava:
sun的悲哀
Apache怒了,威胁说要离开JCP
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
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 “是什么”问题,哈哈,有点绕人,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方式混合,现在******it等动态代理框架都支持静态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来激活角色行为:
账户拥有人操作自己的账户(领域模型),这个账户领域模型发出事件,驱动目标账户进行帐目更新,最后返回给账户拥有人,转账成功。
绕了半天,什么OO
,什么算法,用事件模式就搞定了?
原文:http://www.jdon.com/jivejdon/thread/37976
发表评论
-
Qi4j和NoSql运动
2010-11-16 23:00 156424日一篇Qi4j and the NoSQL ... -
Threaded vs Evented Servers
2010-11-16 22:48 898Threaded vs Evented Servers ... -
BASE: An Acid Alternative
2010-11-16 21:13 935In partitioned databases, tra ... -
eBay 的Scalability最佳实践
2010-11-16 20:52 883用什么来衡量一天没 ... -
Scalability Best Practices: Lessons from eBay
2010-11-16 20:45 820At eBay, one of the primary a ... -
SmugMug 的架构介绍
2010-11-16 20:36 850本文介绍的 SmugMug 是一家提供付费图片 ... -
来自淘宝的架构经验
2010-11-16 18:07 1204日前参加了一场淘宝网 架构师黄裳带来的技术分享,在最后他 ... -
可伸缩性最佳实战
2010-11-16 17:50 560异步 同步调用使得组件和组件之间紧密耦合起来,这样就使得 ... -
伸缩性和可用性反模式
2010-11-16 17:48 685这篇文章讲了伸缩性 和可用性方面的反模式,也按照自己的理 ... -
使用qi4j实现DCI架构
2010-11-16 17:24 2888我曾经DCI架构是什么? 在一文中提到Qi4j框架实现DCI ... -
纵向扩容 vs. 横向扩容
2010-11-02 09:58 5384该文原版著作权属于Malc ... -
云计算在电信应用中的思考
2010-11-01 17:59 908云计算是在网格(Grid)、效用(Utility)和 ... -
真正的线性可伸缩性需要新的模式和中间件架构吗?
2010-11-01 17:27 924在构建线性可收缩应用 ... -
性能与可伸缩性的概念及其关键影响因素
2010-11-01 17:22 1087性能与可伸缩性常常决定企业应用的成败,尤其在 ... -
构建的可伸缩性和达到的性能
2010-11-01 17:19 948实现伸缩性和性能调优的经验所保有的价值容易被低估。两者都是“晚 ... -
可伸缩性的最差实践
2010-11-01 17:02 723引言 在扩展大量大型 ... -
可伸缩性,美妙的可伸缩性
2010-11-01 16:37 1390可伸缩性带来的好处 ... -
大型门户网站架构设计的可伸缩性
2010-11-01 16:34 863我们知道,对于一个大型门户网站来说,可伸缩性是非常重要的,怎么 ... -
可伸缩性设计
2010-11-01 16:27 969好的设计是实现高度可 ... -
为性能和可伸缩性做架构和设计上的Review
2010-11-01 16:05 844部署和体系结构 ...
相关推荐
彭辰阳的讲座PPT :http://www.jdon.com/jivejdon/thread/39722
通信行业周报:中国电信采购DCI波分设备,开放光网络拉开帷幕.pdf
数据中心网络400G和DCI网络架构.pdf
NULL 博文链接:https://oojdon.iteye.com/blog/905779
在大前端辉煌发展、在数据时代的当下我们一起阅读了一篇设计相关的老文:《TheDCIArchitecture》一起来再探索和复习一下相关的设计和思想DCI是数据Data场景Context交互Interactions简称,重点是关注数据的不同场景的...
本文从400ZR,OpenZR+和Open ROADM MSA在内的400G标准开始,着眼于将400G可插拔光模块推向市场。
诸如人工智能(AI)之类的应用迫切需要低延迟,高带宽的网络架构,以支持服务器之间生成的大量机器对机器输入/输出(I / O)。为了确保这些应用程序的基本性能,必须将这些分布式数据中心之间的最大光纤传播限制为...
摇滚动力 RockMotive 为 Rails 提供 DCI 架构。 安装 将此行添加到您的 Gemfile 中: gem 'rock_motive' , github : 'rosylilly/rock_motive' 执照 麻省理工学院执照
美团点评微服务架构实践 基础架构部 张熙 在微服务专题会上的分享
dci-ansible-partner 旧仓库,不再使用
葡萄藤是创建类似REST的API的很好的微框架,但是同时,它的最强之处是它的最弱之处:没有结构,因此您可以决定如何构造代码,如何定义应用程序架构以及这可能会导致……大混乱,因为没有秩序的项目可能变得难以维护...
超融合数据中心IT基础架构方案.pptx
New DR 数据中心网络架构设计 数据中心分区设计 数据中心 & DCI 路由设计 参数设计 数据中心安全设计
AMD k10架构和intel i7架构调试器 总线 内存控制器 调试
Laravel PHP 框架 Laravel 是一个具有表现力、优雅语法的 Web 应用程序框架。 我们相信发展必须是一种令人愉快的、创造性的体验,才能真正实现。 Laravel 试图通过简化大多数 Web 项目中使用的常见任务(例如身份...
基于FPGA的DDR3内存控制器的设计.pdf
布洛PHP 5.4.0 或更新版本的开源框架它是一个像积木一样的微框架。 完整的代码大小小于 400K 字节。 它深受 Slim 框架和其他开源 php 框架的启发。 Bulo 不仅可以用于小型网站,还可以用于大型互联网应用程序。我们...
该方案的设计思想是基于DCI框架,结合Android体系自身的特点,实现了信息公开、图书管理、个人信息管理等主要功能,满足了目前移动应用系统中日益频繁的人机交互的需求。本系统最后通过在不同条件下的实际测试,验证...