解放思想，走出传统三层架构的束缚

又继续用这个框架做了几个项目，项目组的人在无意之中倒也配合我的无知。有人画界面原型，有人直接设计出数据表，然后我就吭哧吭哧根据表建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，都是把领域对象放到缓存中，对象在里面不需要冬眠，是活着的，那么整个业务系统就是有生命的，或者说效率比较高的。

随着对领域对象生命周期的了解，也解开了看示例项目时产生的一些疑惑。现在看的一些示例项目，发现领域对象里往往都有同步方法，而自己以前写的项目，根本没有用到同步功能。现在分析起来，是因为我以前的项目中，领域对象都是贫血的，没方法需要同步，而且领域对象都是request-response期间的，每次被客户端唤醒（比如通过hibernate)的对象其实是不同的对象（业务上可能是同一个对象，但是机器系统里的这些对象的内存块不一样），因为是不同的内存块，所以他们的方法也就不需要同步了。而现在当领域对象有状态后，可以一直活在内存里，那么每个客户端用的领域对象都是可以是同一个（无论业务上，还是机器系统的内存块），那么领域对象的一些业务方法涉及到领域对象自身的数据变化时，就可能需要同步了。

不知道我对业务系统的理解，领域对象生命周期的理解，及领域对象某些方法需要同步的原因的理解是不是正确，如果有偏差，请道友们指正。

还有几个问题要请教道友们：

1，关于领域对象的延迟保存。

如果单机服务器系统，如果突然关机了，那么缓存中的领域对象是不是没有办法被持久化了？

2，关于分布式缓存在系统中扮演的角色。

1）如果用分布式缓存，那么第1个问题是不是就可以解决了？

2）如果机器1的领域对象的方法执行到一半关机了，那么机器2的领域对象会继续执行下去吗？如果会，用什么方案解决的？

3，关于领域对象业务方法的原子性。

一个领域对象A的业务方法需要对象B的参与，但是需要A的数据和B的数据要么同时变，要么同时不变。如果在这个业务方法执行到一半时，关机了，对象A的数据改变了，对象B的数据还没有改变，会不会有这个问题呢？

[该贴被admin于2010-05-08 09:04修改过]