企业应用架构模式读书笔记(二) 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,并没有那么重要。

Leave a Reply

Your email address will not be published. Required fields are marked *