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的组成关系
组成图的意思是结构图
大量的工程实践表明，这两个视角能最有效地描述系统