DDD与DCI的神马与浮云

11-01-30 javagens
我研究了一下DDD和DCI,我觉得适合大型和复杂系统,并不是什么都适合。

如果抛弃八股文的话,我认为DDD主要就是找领域概念和名词,然后弄一个类,然后大家都围绕这个通用名词和概念进行沟通。而不是技术层面的东西。我认为除了这个其他都是来回刷名词啦。

DCI还是个概念的东西,和一种思维方式,好像没什么成熟的DCI开发框架。

其实,总的来说,很多理想者弄了20来年的开发,还是在追求一种完美理念,其实是不可能的,计划总是跟不上变化。

DDD和DCI,一句话就是以客户能理解的领域概念进行开发,其他的都是浮云,而且聚合和仓库等概念,其实也不是技术层面的,还是上面一句话,避免歧义而生。

MVC是否死亡还是得根据很多因素决定,因为MVC只是个简单的层次划分,可以在这个里面进行DDD和DCI或EEE或FFO...

总的来说,无非就是能解偶的就解,没法解的也要解然后弄个中间层,太乱了就弄几个上下文,不行了模块化。其实就是对颗粒的控制。

所以,这是两个问题,一个是弄的CLASS要让客户听懂了,二是把复杂的问题细化,其他都是浮云。因为上下文/模块化/解一解偶/OOP 都是为了让人能够理解可读性好。

其实就是该谁知道的暴露出来,不该的就别暴露,就行了。比如DCI和DDD,让人知道太多新概念了,我认为一种理念出来最好有DEMO,要不就别发布出来。

这个世界概念并不重要,重要的是工具,没工具啥用没有,只是个概念和思维模式,并不能说是完整的框架。

浮云与神马还真多。

         

SpeedVan
2011-01-30 10:24
我对你提出的现象表示肯定,但理解有点出入了,一下是我相应的理解。

2011年01月30日 08:40 "javagens"的内容
其实,总的来说,很多理想者弄了20来年的开发,还是在追求一种完美理念,其实是不可能的,计划总是跟不上变化。

DDD和DCI,一句话就是以客户能理解的领域概念进行开发,其他的都是浮云,而且聚合和仓库等概念,其实也不是技术层面的,还是上面一句 ...

从客户出发是必须的,难道说用户说一套,自己做另外一套?聚合和仓储只是单单概念?仓储明明实现了隔离领域层和基础设施层了,难道这是概念?聚合不是为了单单解耦而解耦的,从另外一方面说它是实现心智模型的一种手段。难道落实到代码上,你才不说是概念?呵呵,这样还真找不出非概念的东西了。而且也强调很多次了,思想和实现是两回事,不能说只有java才能使用这种建模思想吧?

摘录
弄的CLASS要让客户听懂了

并不是Class,DDD很着重说了,交流中模型和类图是两回事,尽管可能很相似。

摘录
上下文/模块化/解一解偶/OOP 都是为了让人能够理解可读性好。

还有很重要一点:提高复用性,也就是避免牵一发动全身。

摘录
我认为一种理念出来最好有DEMO,要不就别发布出来。

理念都要发出来才有人知啊,当然DEMO是理念的更好的展示,但不是只有DEMO才能展示理念。呵呵,你这样说未免太偏激了。

摘录
这个世界概念并不重要,重要的是工具,没工具啥用没有,只是个概念和思维模式,并不能说是完整的框架。

若果没有概念则不会有相应的工具了,概念一定会先于工具出现的。“概念和思维模式”可以理解为思想吧,我认为思想是框架的灵魂,因为思想引出了一种设计,同时框架是服务于设计。即使能读懂框架的代码,但不能读懂框架所表达的设计思想,何来使用好框架呢(为用而用)?就像很多程序员只把面向对象设计当作是代码的规划,而并非把其当作世界映射。

[该贴被SpeedVan于2011-01-30 10:25修改过]

javagens
2011-01-30 13:11
恩,我赞同,我是实用主义者。因为我有两个项目像采用CDI DDD方式开发,但是,我发现没有成熟的可以投入生产的工具或实体框架等技术。所以我有发牢骚的味道。当我发现DCI之后又不能实际投入生产,又感觉有些诱惑和一些思维模式的改变,让我感觉暂时的项目还不如不接触CDI。呵呵。

SpeedVan
2011-01-30 14:29
呵呵,DCI是比较新的,支持他的架构有scala的Actor,而java上的确没有发现类似的框架,但可以用Mixin实现,我记得xmuzyu曾经以他的方式实现过(他是增加场景类),而banq也谈到用qi4j实现,当然这种变相实现就不如直接框架那么优雅了。

猜你喜欢