软件思想的进化和相通

我知道的软件思想至今发展的主要过程:面向过程 -》OO-》DDD-》DCI

始终是一个进化的过程,OO解决了面向过程的封装,但他依然是基于静态的分析;DDD提供了面向应用业务的分析指导,但是他没有直接提供解决对象变化的指导;DCI提供了系统模型分析的指导,他没有解决。。。。。必然有,但我还没有看到。。。。。

思想是渐进式的,对于思想的理解也是渐进的。

OO开始提供了思想基础但是缺少实践方式,在以后的时间里他始终影响着软件的思考方式。DCI的上下文中角色的转变其实也源于此。在传统上我们分析了角色的职能,但是往往忽视了“本体”与“角色”间的区别,从而得到了一个本体中需要实现多个角色的分析结果也是困惑。

DCI中说明了在不同的上下文中本体的角色是可以被替换的,这样本体和角色又再次成为了分隔的独立,互不依赖。如果角色可以在运行时刻被赋予本体,那么AOP、SOA与DCI也建立了关联,同时IOC也成为了将本体组装角色的实践。在各个思想和实践方式中对的内容将共同的被保留和进化,并最终必然的找到契合点。

我认为软件可以理解位自然世界的映射,所有需要软件解决的问题和解决方法必然存在于自然世界中,OO表达了这样的思想。OO是基础和思想的源泉,同时在今后很久(或者永久,除非诞生了全新的软件实践方式)都将是我们思想基础。后来者在研究和学习各种名词和思想之前应该认真深入的思考OO,如果在这个步骤上出现了失误和偏差在后面的过程中弥补是需要付出很多代价的。

时间很短,简单写了。

最后一句写得很好,错过了补课就很吃力。越到后来新的概念理解起来越困难,其实他们也有自己的发展和进化轨道。

只认为DDD和DCI是OO的一个子集。
OO的诞生就是于对复杂业务流程用面向过程处理力所不能及的时候,提出运用抽象和封装的思想运用到编程中去。所以,可以说,OO原本关注点就是客观世界的业务模型。DDD是在之后,层出不穷的技术、方法论,导致OO的“原本关注点”被淡化甚至迷失之后,重新提出要重点回到对客观事物本身的关注。

一下引述一下《精简版》的序文
“在 DDD 以及传统 OO 的观点中,业务而不是技术是一个开发团 队首先要关注的内容,众多的框架和平台产品也在宣称把开发人员 解放出来,让他们有更多的精力去关注业务”
“你就会发现,DDD 其实没有什么太多的 新鲜玩意,它更多地是可以看作是面向对象思潮的回归和升华”
“"DDD"作为传统 OO 范型的探索和升华版,也存在着一些 不足和未涉及的领域……”

而作为DCI,我没有深入研究,只是认为它将处理过程也用OO建模而已。另外,将用例与Context关联,我持有异议。用例的目标单一——重现捕获需求过程,如果还要考虑之后Context,并作为DCI建模重要内容,势必淡化用例的初始目标。

2011年06月10日 17:56 "@showerxp"的内容
用例的目标单一——重现捕获需求过程,如果还要考虑之后Context,并作为DCI建模重要内容,势必淡化用例的初始目标。 ...

用例还是原来的用例,Context和用例关联并没有影响用例本身。关联是因为在原来的用例上可以直接发现Context。可以这么想:用例不知道Context,Context却知道用例——获取用例的人只知道这是用例,但建模者却在这用例中获得更多信息而已。

当然,不排除为了更好的获取Context来调整用例,但我不认为用例失去本意了。

用例本身作为捕获需求的半形式化工具,其根本任务就是重视捕获需求过程,这一过程使得我们更好的认知问题域中的复杂业务处理流程。重现捕获需求如此重要,以至于该过程的结果——用例本身都显得不太重要了。这样DCI把关注重点放在这种主观意识理解的产物——用例身上,势必需要对用例赋予新的责任。比如用例要比较稳定,不能时常修改,而认知陌生事物过程本身就是一个由浅入深的过程,所以用例不可能一步到位,不做修改或者删减;比如用例中的内容要便于软件实现,势必掺杂代码思维,而弱化业务需求本身……

以上是我对DCI肤浅认识,现在看来,需要一个DCI实现案例,做具体分析。我说的案例当然包括用例编写过程,而不是涉及到用例只是一张用例图简单带过。

我也认为DDD DCI神马的属于OO的子集,是对原有思想的阐述和实践指导,因为OO主要提供了思想但是缺少实践的指导。随着实践和思考的深入,对于一种思想后来者的境界与深度超越始祖,也不是特别的事情。

用例的核心就是参与者与事件,其中事件的核心必然是上下文(因为其不可能是孤立存在的),其中的内容类似于DCI的context。用例着重描述了参与者与事件的关系,但是同一参与者“角色”的变化并没有参与核心的分析过程。

同时用例着重于发现用户的业务过程和用户需求,但是在过程、需求与程序模型之间还存在着间隙。从业务模型到软件模型的转化有时候并不是一比一能够完成的,在这一层DCI提出了一种实践方式。用例与DCI并不属于同一层次的内容。

如果说用例是系统行为的描述,那么DCI可以看成是系统行为的实施。
一个是目标,一个是实施目标的手段。
一个是方向,一个是通往这个方向的道路。

哪位朋友提供一下DCI的原始出处,我一直没有找到这个好框架的发现人,多谢。。

哪位帮忙提供一下DCI的原始出处,我一直很关心发明DCI的大师,多谢了。

哪位帮忙提供一下DCI的原始出处,我一直很关心发明DCI的大师,多谢了。

google吧,wiki上好像有很多资源

哪位知道DCI的出处,我很关注写DCI的这位大牛,请知道的朋友发一下吧。多谢。。