领域模型浅析
最近taowen同学连续发起了两起关于贫血模型和领域模型的讨论，引起了大家的广泛热烈的讨论，但是讨论(或者说是争论)的结果到底 怎样，我想值得商榷。问题是大家对贫血模型和领域模型都有自己的看法，如果没有对此达到概念上的共识，那么讨论的结果应该可想而知，讨论的收获也是有的， 至少知道了分歧的存在。为了使问题具有确定性，我想从一个简单例子着手，用我对贫血模型和领域模型的概念来分别实现例子。至于我的理解对与否，大家可以做 评判，至少有个可以评判的标准在这。
一个例子
我要举的是一个银行转帐的例子，又是一个被用滥了的例子。但即使这个例子也不是自己想出来的，而是剽窃的<
。当钱从一个帐户转到另一个帐户时，转帐的金额不能超过第一个帐户的存款余额，余额总数不能变，钱只是从一个账户流向另一个帐户，因此它们必须在一个事务内完成，每次事务成功完成都要记录此次转帐事务，这是所有的规则。
贫血模型
我们首先用贫血模型来实现。所谓贫血模型就是模型对象之间存在完整的关联(可能存在多余的关联)，但是对象除了get和set方外外几乎就没有其它的方
法，整个对象充当的就是一个数据容器，用C语言的话来说就是一个结构体，所有的业务方法都在一个无状态的Service类中实现，Service类仅仅包
含一些行为。这是Java
Web程序采用的最常用开发模型，你可能采用的就是这种方法，虽然可能不知道它有个“贫血模型”的称号，这要多
亏Martin Flower(这个家伙惯会发明术语！)。
包结构
在讨论具体的实现之前，我们先来看来贫血模型的包结构，以便对此有个大概的了解。
贫血模型的实现一般包括如下包：
- dao：负责持久化逻辑
- model：包含数据对象，是service操纵的对象
- service：放置所有的服务类，其中包含了所有的业务逻辑
- facade：提供对UI层访问的入口
代码实现
先看model包的两个类，Account和TransferTransaction对象，分别代表帐户和一次转账事务。由于它们不包含业务逻辑，就是一个普通的Java Bean，下面的代码省略了get和set方法。
代码实现
现在来看实现，照例先看model中的对象：
Java代码
Repository接口属于领域层
可能有人会将Repository接口，相当于贫血模型中的DAO接口，归于基础设施层，毕竟在贫血模型中DAO是和它的实现放在一起。这就涉及 Repository 接口到底和谁比较密切？应该和domain层比较密切，因为Repository接口是由domain层来定义的。用TCP/IP来类比，网际层支持标准 以太网、令牌环等网络接口，支持接口是在网际层中定义的，没有在网际层定义的网络接口是不能被网际层访问的。那么为什么在贫血模型中DAO的接口没有放在 model包中，这是因为贫血模型中DAO的接口是由service来定义的，但是为什么DAO接口也没有放在service包中，我无法解释，按照我的 观点DAO接口放在service包中要更好一些，将DAO接口放在dao包或许有名称上对应的考虑。对于领域模型，将Repository接口放入 infrastructure包中会引入包的循环依赖，Repository依赖Domain，Domain依赖Repository。然而对于贫血模 型，将DAO接口放入dao包中则不会引入包循环依赖，只有service对DAO和model的依赖，而没有反方向的依赖，这也导致service包很 不稳定，service又正是放置业务逻辑的地方。JDepend这个工具可以检测包的依赖关系。
贫血模型中Facade有何用？
我以前的做一个项目使用的就是贫血模型，使用了service和facade，当我们讨论service和facade有什么区别时，很少有人清 楚，最终结果facade就是一个空壳，它除了将方法实现委托给相应的service方法，不做任何事，它们的接口中的方法都一样。Facade应该是主 要充当远程访问的门面，这在EJB时代相当普遍，自从Rod Johson叫嚷without EJB之后，大家对EJB的热情降了很多，对许多使用贫血模型的应用程序来说，facade是没有必要的。贫血模型中的service在本质上属于应用层 的东西。当然如果确实需要提供远程访问，那么远程Facade(或许叫做Remote Service更好)也是很有用的，但是它仍然属于应用层，只不过在技术层面上将它的实现委托给对应的Service。下图是贫血模型的分层：
从上面的分层可以看出贫血模型实际上相当于取消掉了领域层，因为领域层并没有包含业务逻辑。
DAO到底有没有必要？
贫血模型中的DAO或领域模型中的Repository到底有没有必要？有人认为DAO或者说Repository是充血模型的大敌，对此我无论如 何也不赞同。DAO或Repository是负责持久化逻辑的，如果取消掉DAO或Repository，将持久化逻辑直接写入到model对象中，势必 造成model对象承担不必要的职责。虽然现在的ORM框架已经做得很好了，持久化逻辑还是需要大量的代码，持久化逻辑的掺入会使model中的业务逻辑 变得模糊。允许去掉DAO的一个必要条件就是Java的的持久化框架必须足够先进，持久化逻辑的引入不会干扰业务逻辑，我认为这在很长一段时间内将无法做 到。在rails中能够将DAO去掉的原因就是rail中实现持久化逻辑的代码很简洁直观，这也与ruby的表达能力强有关系。DAO的另外一个好处隔离 数据库，这可以支持多个数据库，甚至可以支持文件存储。基于DAO的这些优点，我认为，即使将来Java的持久化框架做得足够优秀，使用DAO将持久化逻 辑从业务逻辑中分离开来还是十分必要的，况且它们本身就应该分离。
结束语
在这篇文章里，我使用了一个转帐例子来描述领域模型和贫血模型的不同，实现代码可以从附件中下载，我推荐你看下附件代码，这会对领域模型和贫血模型 有个更清楚的认识。我谈到了软件的分层，以及贫血模型和领域模型的实现又是怎样对应到这些层上去的，最后是对DAO(或Repository)的讨论。以 上只是我个人观点，如有不同意见欢迎指出。