DDD精彩

MS

STST

这难度太高了

有一个就很难的了

也许我工作的环境一般,能把SOLID简要描述一下的,都还没有遇到

SOLID还只属于OOD层次,OOA层面就更加没碰到了

Scrip

因为领域驱动设计的大神比较多

MS

用的人不多吧

A

可能是会用的人不多吧

MS

是啊，大项目也没法用吧，要协调的东西太多

STST

全世界软件工程发展到现在,OOX应该是最核心的一块了吧

，还要Great Skill,这高度太难了

布鲁克斯 之类的肯定没问题了
A

领域驱动设计像下围棋，刚开始听名字我确实被吸引了，但是后来发现他跟技术框架是紧密结合的，开始让我觉得实用性大打折扣；

STST

我看了DDD,深知其是在OOA的基础上进行工作的

抽象高度不是一般地高
A

DDD就是面向对象设计的精华吧，并不是新东西，个人觉得

STST

绝对在设计之上

属于分析层面的,至少从DDD那本书的内容来看是的

更多的是引导分析的过程

A

DDD就是设计，所以很多教材都试图通过技术框架（如EF）或代码来解释DDD

STST

我更多地认为是引导如何分析需求,描述需求上,技术设计倒不是重点

这是我读DDD这本书后的深刻感受

A

当然我个人对这类用代码来解释DDD的方式比较不认可，我觉得学DDD应该是要得出对软件系统的优秀的表达方式，而不是用DDD来指导编程

DDD得出的结果应该还是类图，而不是程序代码

STST

而且还是需求领域里的类图

而不是具体设计时那么细致的类图

A

是，同意

STST

DDD我看的过程中,无法用文字描述那种兴奋的感觉

A

关于DDD得出的类图要怎么表达才是优秀的，这个需要个人自己去体会，因为至今没有看到有关这么方面总结。

STST

讨论DDD的话题,基本不需要代码

DDD我一直在做摘抄,最后发现基本整本书都快摘抄下来了

我看书有摘抄的习惯,发现DDD,包括DDD Quikly没法摘抄

因为发现全是亮点

A

我一直希望找出一个类图的表达方式，通过一个类图就可以表达一个模块的来龙去脉，不需要其它什么活动图顺序图之类乱七八糟的，也不需要太多的文字描述，你认为可否做到

STST

那不可能，类图只是一个视角

观察一个模块存在无数种视角，类图，序列图，状态图。。。。。，而这些视角是无法叠加的

所以你不要指望用一个图展现整个模块

目前，经过大量实践，在分析阶段，有两个视角尤其重要

类图，还有一个组成图
A

组成图？

STST

这两个视角一个展现IS的层次关系，一个展现Has的组成关系

组成图的意思是结构图

大量的工程实践表明，这两个视角能最有效地描述系统