算是DDD一篇文章的读后感吧

05年底的时候，我们项目组要开发一个ERP的系统。我们选择了jsf(ADF)+spring+hibernate的架构进行系统开发，3层分层架构进行设计开发。技术经理把表设计好，跟我们讲清楚表和表之间的关系，然后我们写model,dao,manager,form来实现。那时候我根本没有什么面对对象的设计或者面向数据库的设计的概念，感觉应用系统主要就是设计表之间的关系，数据库的一系列操作。这样浑浑噩噩过了1年多，在jdon上了解了设计模式，但是那时总觉得很难把设计模式落到实处。可能这也是面向数据库设计的结果吧，领域对象都是贫血的，没有行为，只是一个数据的容器，所以也谈不上封装变化什么的。

又继续用这个框架做了几个项目，项目组的人在无意之中倒也配合我的无知。有人画界面原型，有人直接设计出数据表，然后我就吭哧吭哧根据表建model对象，然后利用自己写的模板，快速生成dao,manger,form,jsp界面。呵呵，我估计现在有些公司也是这么做的，结果很明显的，一开始开发速度很快，随着客户的需求变化，你的manager层的逻辑代码也越来越复杂，model中也出现了一些不想看到的字段，再最后，有些manager的业务方法，都不忍心看了。

一直感觉自己徘徊在OO设计的门外，入不了门，直到最近对业务系统设计有了新的认识，以及明白了领域对象生命周期这个概念。

我现在已经明白对系统进行OO设计还是数据库设计不是jsf+spring+hibernate架构所引导的，而在于你是不是有OO的思想去引导你的设计。但是这个架构，或者说这个架构的一些流行的例子确实会给经验不深的设计者产生束缚，会让技术架构影响了对象设计，从而限制了设计者对对象设计的想象能力。用这个架构的时候，领域对象一般是贫血的，jsf页面直接绑定领域对象，然后在web的action里调用manager层进行对象的数据交互和持久化。在这样的思路下，领域对象好像只是一个临时性的数据容器，为request-response阶段业务数据的交互，持久化服务的，他没有舞台去表现他的表达业务的能力。这难道就是领域对象应该扮演的角色吗？把自己的舞台让给更像是技术对象的service来表演？没有更好的方法去表达一个系统吗？当我看到《领域对象设计》这本书的第6章领域对象的生命周期这一章时，看到banq的cargosimple中用的xxxInMem.java这样的仓储类时，我发现原来可以换个角度来理解一个业务系统的。业务系统是领域对象的活动场所，领域对象本身具有的数据和他的行为才是一个业务系统最核心的东西，而数据库是对象冬眠的一个地方（对象冬眠好象有点不恰当，因为数据库做的只是对象数据的持久化）。而orm这些框架，变通的实现了对象的冬眠，及对象的唤醒。我觉得这样去了解一个业务系统太棒了。因为领域对象有生命的，所以设计师可以决定领域对象存活多少时间。比如说，我以前的项目中，领域对象的生存周期都是在一个request,response中的，时时刻刻都被冬眠，造成的结果就是整个业务系统里，没有活动的领域对象，都是冬眠的对象，而要使用这个系统，就需要先把领域对象唤醒，然后进行业务交互。而现在看的一些例子，dddsample,或者JiveJdon，都是把领域对象放到缓存中，对象在里面不需要冬眠，是活着的，那么整个业务系统就是有生命的，或者说效率比较高的。

... ...

新项目要用到DDD面向领域设计开发(DomainDesignDevelopment)，team中有人推荐了上面的文章(http://www.jdon.com/jivejdon/thread/38851)。

其实长期以来我们的项目开发也都是贫血模型，基本上就是对于sql的封装，把需要的数据持久化到db中。DDD这个概念显然是好的。这样我以后估计可以用上设计模式了。目前一直感觉设计模式离自己很遥远，似乎除了原来上学的时候写的扫雷这样的游戏可以使用一下以外，感觉几乎用不上。但是对于DDD的问题，还是有不少的。

就像上面那个帖子提到的（我没有贴出来）

* 需求变更

坦白的说，如果需求变更太快，很可能会产生很大的问题。很快产生的需求大多是用户拍脑袋想出来的东西。我认为这个应该算我国现阶段it市场的基本国情。各个行业对于it系统大多都是刚刚起步，并且这些企业本身也都处于起步阶段（和国外同行业对比）。因此他们对于domain的认识也是刚刚开始，业务要素之间的关系有可能是拍脑袋拍出来的。在code阶段，的问题就是，需求变更，有可能意味着domain之间的关系乱七八糟。因此domain开发最应该适用的是行业的老大。对于业务有一个清楚的认识和规划。而并不适应以项目为开发背景的小公司

*事务处理

这个问题是那篇帖子最后楼主提出的问题。显然，DDD开发可以带来的是代码的重用。但是上层的需求可能来自于多个domain操作的整合，那么在代码上如何进行控制？

*性能问题

之前的开发上我们遇到的性能问题大部分来自于DB层，经过N年的积累后，数据量不断膨胀，导致许多东西不得不做特殊处理。不过我觉得这个问题应该在domain开发上有许多前人的经验，因为在我看来DDD开发适合的就是对行业很了解的大企业，因此他们肯定最先遇到数据量巨大的问题。如果系统做做垂直切割，domain模型之间的关联处理很可能比较麻烦，即使有 webservice。

接下来，自己要多关注思考一下DDD开发。和重构和设计模式一样，DDD也不是一天能够练成的。然后就是跟在一帮牛人的后面学习，O(∩_∩)O哈哈。觉得有一帮大哥带着就是比较爽，虽然自己也不年轻。。。。。。。。

学习！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!