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

1、以领域模型为中心我没有异议。但楼主的落地方式我认为有打着DDD的牌子，实施面向过程的嫌疑。
2、楼主的原文是强调落地，落地当然要关系细枝末节；
3、清晰的分层 不等于  DDD 。

1、我好崩溃，这不是一个概念，再次重申，仅仅名字一样而已

2、你可以了解一下dwr，或者我写的一个实例：一个dwr+spring+hibernate的示例

3、你可以了解一下事务拦截器：
org.springframework.transaction.interceptor.TransactionInterceptor
以及名称匹配自动代理：
org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator

4、Bus和Bus之间会互相调用是存在可能的，原因以职责为中心分配行为，在我这个系统文章中已经说明了

1、没必要反应这么强烈吧，讨论问题而已；说不清楚的话慢慢说；

2、我会去看你的实例；

3、事务拦截器我没有必要看，如果这些概念都不懂，没必要在这里跟你再讨论下去。你没有理解我的意思。
  例如
     class1 的某方法声明成Requre  new，
    
     class2 ，class3的方法调用class1的，它们对class1的事务有不同的要求，你如何处理？
    
4、本质上就是面向过程 

恕我愚钝,楼主的例子中除了CRUD,没有看到什么复杂的业务逻辑.

楼主不妨用你的框架实现一下这个例子
http://www.iteye.com/topic/57075

当你在质疑我的文章的时候，我首先想到的是，我的文章是否把我的思想表述清楚，也许我真应当重构一下我的文章了。

你给的这篇文章谈的是贫血与富血的讨论。Robbin似乎一直倾向于富血，但我毫无疑问是倾向于贫血而质疑富血的。

Service可以省，因为有dwr支持，DAO可以省，因为有hibernate的支持。在我看来，值对象就只应当包含要持久化的数据，和表间的关系（值对象的建立应当基本上与领域模型中的概念类（不包含行为）保持一致，注意这里的值对象概念是hibernate中的值对象概念，而不是DDD中的值对象概念）。而领域模型中的那些行为，应当全部放到BUS中，即领域层。这个意思就是我所说的数据与业务逻辑分离。

这篇文章可能理论概述多了一点儿，很难把我的意思表达清楚。我正在策划写一篇新的文章，用一个实例来讲述我怎样用领域驱动设计去分析和设计一个系统的。

现在又多少大型项目用了真正的DDD，DDD虽然已经出来了这么多年了，但是用起来还是蛮麻烦的，也是蛮复杂的。概念上是好的，Repository，Domain Event，Factory，Bus很多东西都是换了一个名字。

DDD可行，很好，没有在大型项目中系统的用过。小项目的DDD不能体现出其中的魅力。

  前面讲的几章节我都很仔细看了,对我映像非常深刻。绝大初级程序员，完成一个功能，就敷衍了事了,就知道大概流程,就我公司一位女程序员,我们经理跟她说需求的时候，话没说完，就说：“这个我懂了”。当时老板很高兴，招了人才，到真实开发的时候，我就问她的说懂的那个流程，她一句：“我也不知道”,叫我问经理.我无语.
  开发建立在某个模式之上，然后复查自己的某个领域的程序设计,总结.这样可以提升自己.
  
  

功力有限，越往后看越看不懂。回头好好补课，就从DDD开始吧。

关于领域驱动设计，一直想在项目中实施，但是一直没有发现成型的方案。如果仅仅划分几个层次，限于贫血模型和充血模型的讨论，那么我们还是老一套开发，那就是结构化的，刚性的框架设计。就以上讨论，大家主要集中于两点:
1，怎样抽取领域模型。
   楼主重点说明了领域模型的重要性和大致概念，并举了“付款单生成凭证”实例。
   楼主又提到在一个员工信息管理系统中，员工领域模型映射成了2个类，Employee, EmployeeBUS。Employee类包括各个属性，EmployeeBUS类包括行为。个人觉得和普通意义上的领域模型驱动不一致。普遍来讲，领域模型包括聚合根，值对象，服务，仓储等等概念。
如果能给一个完整的实例可以更加深入讨论。

我来举一个例子，
比如物流系统中，客户要下一个订单(Order)，可以设计一个关于订单的领域模型，Order是聚合根，包括很多商品（Product），做订单时候要查询这个客户的余额，那么需要设计一个服务类（OrderService），与早期的Service 类不一样，仅仅是业务规则而已。OrderService 向Application发出消息“需要某帐户余额”，由Application来调用Account类提供余额信息。
Application是Transaction边界。这个消息也可以称之为Domain Event。
这个消息框架的设计，有2种方案:（1）观察者模式（2）JMS 。
利用JMS处理信息的时候，可以采用同期和非同期，根据自己的业务要求来定。

2，怎样基于领域模型进行框架设计。
各位同学如果有兴趣的话，请看看这份框架设计http://dddsample.sourceforge.net/
dddsample提供了一个很好的例子，不过自己在借鉴的过程中要区别使用。
BigBlue的一些疑惑也是我看这份代码的疑惑。如果大家有兴趣的话，我们再开一贴，专门讨论怎样借鉴dddsample来进行领域驱动设计，呵呵。
暂时先借一个地方说说，从dddsample里我的疑惑:
（1）事务的一致性处理
要保持事务的一致性，在跨多个领域模型更新操作的时候，必须是同期处理。如果采用非同期处理，要保持事务的一致性，就要采用分布式事务。
有没有折衷的办法呢？dddsample里用的是非同期处理，没有采用分布式事务处理。dddsample为了提高可用性，而牺牲了一致性。

（2）增删改和查询统计的区别处理
在目前还是以关系型数据库为主流的持久化时代中，查询统计一般都是通过存储过程来实现的。这样一来业务逻辑就很有可能分散在领域模型和存储过程两个地方了，不方便维护。各位同学有没有好的方案？http://code.google.com/p/cqrs4j/提供了一种方案，有谁在开发中实践过这个框架吗？

总之，业务层采用Domain + DomainEvent + Cache，表现层适当采用Ajax，应该能够构建一个灵活的，柔软的框架，代码质量也会有所提高。

这篇文章我犹豫了数天，最后还是贴上来了，但不得不承认比较失败，即有许多地方没有描述清楚，也有许多地方认识还不深刻，但也许可以提出来作为一次有益的尝试吧。

我这个人崇尚大胆地改造，我希望将领域驱动设计实实在在地运用到我们的开发中，并大胆地改造我们的开发模式。但这依然是一个艰巨的工作。希望这里能作为一个我们探索和探讨的场所吧:)