企业应用架构模式读书笔记(二) Domain Model

  这个笔记主要记录一下领域模型。

  第一次听说领域模型是在JavaEye的一个帖子上。 也就是那个经典的robbin总结。那时候看是一头雾水，根本不知所云，虽然当时已经是大三下半学期，开发了学院的那个CMS。从IBM回来以后，开始着手重新启动APIS的开发，同时引入了Spring框架。一些项目上的心得，再加上对APIS设计上的疑惑加在一起，重新再看那篇帖子，真是豁然开朗啊。同时也去了Martin Fowler的Bliki上看了那篇批判贫血模型的blog。

  其实所谓的领域模型，我在使用Hibernate的时候，就已经使用了这个模式。不过在Martin Fowler写这本书的时候，Hibernate不知道存不存在，即使存在，也肯定很不成熟吧。通过O-R Mapping，我们建立了领域模型。比如说，对于PoEAA书里那个例子来说，建立了Contract, Product, RevenueRecognition三个领域对象。这些对象之间通过引用互相联系。同时把一部分验证、计算的逻辑放在了领域对象里。非常重要的一点是，这些领域对象，或者说这些类，可以存在继承或者关联关系，也拥有多态、封装的特性。可以说把OO发挥得淋漓尽致（不过发挥过头了也不好）。先贴一张图吧，就是书里的类图。

  (附带说一下，CSDN里图片上传以后的那个预览窗口里那些文字不知道为什么还保留着，根本没有用。这个FCKeditor改得不够？)

 三个领域对象互相关联。同时对不同的产品，使用了不同的计算策略(Strategy模式)。

  底层的数据映射模式，可以使用Data Mapper，或者是Active Record(就是RoR里的那个)，前者通过另外一个类似DAO的类来处理CRUD，而Active Record在领域对象内部处理持久化。Fowler的观点好像是不需要DAO了。

  另外，对x血模型我也不是很清楚。有很多种说法，就是在JavaEye上看到的，robbin说的都不一样。最典型的就是关于贫血模型了(Anemic Domain Model)，根据Fowler的说法，就是把所有的Domain Logic抽到Service 层以后，只有单纯的getter和setter的领域对象模型。而充血模型(Rich Domain Model)，在底层那些POJO里就包含了一部分的逻辑。但把事务处理等工作交给了Service Layer。另外还有一个胀血模型(Bloated Domain Model)，是一个反模式，把所有的工作都交给了领域对象，包括事务(因为事务总是经常要涉及到其他部分)。

  还有一个失血模型，英文不知道，内容也不太清楚。这是我的理解。还有另外一种说法，同样没有失血模型的描述。也是在JavaEye上，robbin总结的帖子。

1. Anemic Domain Model: Service --> DAO --> Domain Object
2. Rich Domain Model: Service -->Domain Object <--> DAO
3. Bloated Domain Model: Domain Object <--> DAO

 如果是这样的话，其实这和Fowler所定义的的贫血好像并不一样。脑子有点被搞糊涂了，呵呵。不过我想追究这么多，搞清楚概念也没什么用。重要的是自己去实践一下，哪个好用，易于扩展、易于维护。到底是不是纯粹的OO，并没有那么重要。