一堂如何提高代码质量的培训课 之 领域驱动设计

1.我并不是要进行对与错的质疑,而是质疑是面向对象还是面向过程,是Eric的DDD,还是其它的.我并不认为你的方式是Eric的DDD的一个落地,因此才建议你改名字,以免引起混淆和无谓的争议;

2.我要说的Service是指Eric所谓的中等粒度,无状态的分割领域和应用的那一层次.你通过DWR实现了将BUS暴露出去(这只是个技术实现),但是你的Entity(Bus)如果每个都映射到一个领域概念,那么肯定是细粒度的.除非在你的BUS中分割出来一部分类不映射到失体,承担粗粒度的职责.因此不是Service可以省略的问题.而是你的应用中省略了Eric的Service;

3.Eric的DDD中不提倡DAO,而是根据实体的聚合关系划分不同的仓库.

4.看过DDD的人,会对你所说的值对象感到不知所措;

最后,我并不是要表达我多么崇拜DDD,你要是不符合Eric的DDD就是多么的谬误,说了这么多核心要表达的就是,楼主的东西和Eric的东西差异很大,已经不适合在同一个名号下来讨论了.

其实你的前几部分我都看了,说实话还不错,但是最后这一部分在吊足了大家胃口的同时没有看到预期的东西.
你确实是在做大胆的改造

DDD有点阳春白雪的意思.
:)

业务是复杂的，建立Domain model对很多人来说比较困难,这实际上阻碍了DDD的普及。建一个好的Model就像作家写一部成功的小说。
DDD是建立在OO的基础上。OO的炒作已经30年了，提起OO似乎都有落伍的嫌疑，但是又有多少人在真正在用OO呢？多少人和机构是在挂羊头卖狗肉呢？从另一方面我也在反思，不能普及的技术是好技术么？很多人不也是用过程八项目做出来了么？



Domain Event研究的不多，能否分享一下经验


   没有仔细研究过dddsample的这个方面。分布式事务很麻烦，特别是异构的系统，有时候不得不牺牲一致性。
    想听听你的看法。


    如果不是性能问题，我一直不赞同使用存储过程，这个问题我一般是这么考虑的：
    .NET领域可以选择Linq来解决查询问题，
     JPA可以通过JPQL或者Criteria API来解决


把这些内容整理一下就可以新开一贴了

TO BIgBlue
呵呵，我正准备在下一个项目中实施目前所了解的DDD方面的知识，现在纯属纸上谈兵。
有DDD实战经验的大佬们能否站出来给各位同学讲讲心得体会啊。

如果我是在一个月以前看楼主这文章的话，绝对是觉得看不懂，全是空谈，但现在不一样，公司 来了个牛人，在这一个月的时间里，我以前一直理解的java面向对象完全有了一个新人认识，再次感谢楼主提供这么好的东西

DDD这方面的东西，一直在发展，半年前还没有听说过传说中的CQRS呢，最近开始有人准备做了，如前面的一位同学说的，DDD，特别是Eric说的DDD，有点阳春白雪的样子，永远都是那个例子。 DDD方向的实践，什么是真正的DDD，这样的问题才是最重要的。

有很多DDD的实现，opensource的，但是每个是一个样子，每个有自己的理解。如果在一个简单项目里面做了DDD，或者是所谓的DDD，没有多少参考价值。 也尝试着DDD，但是越做到最后越是迷茫。难道充血了，难道加上了factory，换成了Repository就是DDD了吗？这样的DDD跟其他的又有什么本质的区别呢？

请有经验的多分享。

楼主好像有些概念不是很明确，最好能辅以代码来说明。看了以后也感觉有一些与BigBlue提出的类似的疑惑，尤其是值对象啥的。

如果有代码说明可能就更容易看明白了。

每个人心中都有个自己的DDD，即使他自认为得到了eric的真传。

楼主对领域模型的理解我很赞同，但是楼主对领域模型的实施我没有搞懂，而且去掉service和dao我是反对的。