神马文学网Domain Driving Model Design之总结与我的选择
来源：百度文库 编辑：神马文学网 时间：2024/05/05 07:10:05
摘自：http://www.blogjava.net/langds/
首先引用说明一下Domain Model 的定义：
Domain Model ： An object model of the domain that incorporates both behavior and data.
Domain Model 分两种：
1 Simple Domain Model (Active Record)
它的特点是POJO和TABLE STRUCTURE一一对应，建模基于数据库设计。Hibernate走的就是这个路子，说它贫血，意思就是指它只有data，没有behavior。(但我们实际可以通过HBM文件的定义和映射，在PO中适当的加入一些基本的业务逻辑的。)
在这种模式下，POJO自己的CRUD操作都应该放在自己的类里面。其他复杂的业务逻辑会放到外面的Service layer。
2 Rich Domain Model (Data Mapper)
它的特点是POJO和TABLE STRUCTURE并不一一对应，建模天马行空，完全取决于业务逻辑。domain object和table之间的mapping，由Data Mapper完成，domain object不用管数据表是何等结构，甚至不用管Data Mapper怎么操作。
1.识别某种业务行为的一个很确定的原则：
domain logic只应该和这一个domain object的实例状态(并非“持久”状态)有关，而不应该和一批domain object的状态有关.
进一步的说：主要看logic是否只和这个object(注：指自身)的状态有关，如果只和这个object(注：指自身)有关，就是domain logic；如果logic是和一批domain object(注：指同类型的实体)的状态有关，就不是domain logic，而是business logic。
2.Domain Model 与 Hibernate PO 的区别：
领域模型的代码实现需要用一组互相协作的类来完成，每一个或者一组类承担这个领域模型的某个特征。而Hibernate的实体类只不过是其中的一组类，它承担的职责就是保持领域模型的状态的。
3.基于Domain Model 分析与设计的方法规则：
应该由领域模型来驱动你的软件内在规则，由需求驱动你的软件外在交互.
最后，我想补充的是：根据目前的O/R Mapping技术，我们在实际项目开发中，能真正做到 富领域模型 还不现实(因为我们还要考虑诸如性能、目前O/R持久化特性等等问题)，更何况，我们的MODEL DATA最终需要被持久化，因此，我比较反对在DOMAIN MODEL 中直接通过任何方式做任何持久化操作，因为这会让你所设计的MODEL无法独立化，难以单元测试，并且与加入了一些外界无关的东西，这不符合对象的本质(对象本身是不能持久化的)。虽然我们做不到完整意义上的Domain Driving Model Development，但我们可以在项目实际开发中因为性能、结构简化等等上面得到补偿，这已经值得欣慰了。
首先引用说明一下Domain Model 的定义：
Domain Model ： An object model of the domain that incorporates both behavior and data.
Domain Model 分两种：
1 Simple Domain Model (Active Record)
它的特点是POJO和TABLE STRUCTURE一一对应，建模基于数据库设计。Hibernate走的就是这个路子，说它贫血，意思就是指它只有data，没有behavior。(但我们实际可以通过HBM文件的定义和映射，在PO中适当的加入一些基本的业务逻辑的。)
在这种模式下，POJO自己的CRUD操作都应该放在自己的类里面。其他复杂的业务逻辑会放到外面的Service layer。
2 Rich Domain Model (Data Mapper)
它的特点是POJO和TABLE STRUCTURE并不一一对应，建模天马行空，完全取决于业务逻辑。domain object和table之间的mapping，由Data Mapper完成，domain object不用管数据表是何等结构，甚至不用管Data Mapper怎么操作。
1.识别某种业务行为的一个很确定的原则：
domain logic只应该和这一个domain object的实例状态(并非“持久”状态)有关，而不应该和一批domain object的状态有关.
进一步的说：主要看logic是否只和这个object(注：指自身)的状态有关，如果只和这个object(注：指自身)有关，就是domain logic；如果logic是和一批domain object(注：指同类型的实体)的状态有关，就不是domain logic，而是business logic。
2.Domain Model 与 Hibernate PO 的区别：
领域模型的代码实现需要用一组互相协作的类来完成，每一个或者一组类承担这个领域模型的某个特征。而Hibernate的实体类只不过是其中的一组类，它承担的职责就是保持领域模型的状态的。
3.基于Domain Model 分析与设计的方法规则：
应该由领域模型来驱动你的软件内在规则，由需求驱动你的软件外在交互.
最后，我想补充的是：根据目前的O/R Mapping技术，我们在实际项目开发中，能真正做到 富领域模型 还不现实(因为我们还要考虑诸如性能、目前O/R持久化特性等等问题)，更何况，我们的MODEL DATA最终需要被持久化，因此，我比较反对在DOMAIN MODEL 中直接通过任何方式做任何持久化操作，因为这会让你所设计的MODEL无法独立化，难以单元测试，并且与加入了一些外界无关的东西，这不符合对象的本质(对象本身是不能持久化的)。虽然我们做不到完整意义上的Domain Driving Model Development，但我们可以在项目实际开发中因为性能、结构简化等等上面得到补偿，这已经值得欣慰了。
Domain Driving Model Design之总结与我的选择
闲谈Domain Model & Transaction Script
域模型（Domain Model）
Dependency Injection For Rich Domain Model 1
Transaction Script 和 Domain Model--恶魔地穴
Domain-Driven / Model-Driven(转 domaindrivendesign.org)
InfoQ: Eric Evans on Domain Driven Design
Kemp‘s Model for Instructional Design
Dick and Carey Instructional Design Model
DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design
Transparent Dependency Injection For Rich Domain Model 2
博客园 - 企业设计模式读书笔记 Domain Model
实战DDD(Domain-Driven Design领域驱动设计)
实战DDD(Domain-Driven Design领域驱动设计)
领域驱动设计 Domain-Driven Design - RicCC NHibernat...
实战DDD(Domain-Driven Design领域驱动设计)
我对Entity Data Model的一些理解
爱情与事业,我的选择
实战DDD(Domain-Driven Design领域驱动设计:Eric Evans D...
SEO入门之搜索引擎查询指令site、link和domain的区别
Domain-Specific Modeling (转与 ITarchitect)
总结2009，展望2010。我与安利的不解之缘
NLP之设计（Design）
我的学习总结