转载:浅谈领域驱动设计

09-11-03 oojdon
         

无意发现一篇文章,写得很不错,来自Anders小明的Blog,原文地址:

http://www.blogjava.net/AndersLin/archive/2009/05/07/269496.html

摘取部分,大家可以去看一下原文

摘录自"Anders小明的Blog"
为何要面向对象?

1. 面向对象是自上而下的开发方法;这种方式对于迭代增进式的结构化过程来说成本是最低的;

2. 数据和业务逻辑的绑定性,采用面向对象容易操作和沟通(即实施成本低),同时有助于区分状态逻辑和任务逻辑;

3. 业务逻辑的差异性,同一个业务逻辑针对差异性数据有区分做法,采用面向对象容易维护;

摘录自"Anders小明的Blog"
生命周期相关的聚合和组合关系。关系数据库中所保存的是系统分解后的表示,即关系被分解了而不是被表达了,外键对数据关系只起到一种约束作用,它对于查询语句的构建并没有直接的影响。所有数据之间的关系都必须在查询的时候明确指定出来,即调用者必须拥有数据关系的知识,而不是数据本身拥有这些知识.在如下的SQL语句中

“select * from a, b where a.fldA = b.fldB and a.fldC = 1 and b.fldD = 2”

其中,a.fldA = b.fldB 可以称为关联条件,而a.fldC=1可以称作是坐标条件。

SQL的复杂性很大程度上来源于我们频繁的需要在各处指定完全一样的关联条件而无法把它们抽象成可复用的组分.在ORM所提供的对象空间中,对象之间的两两关联只要指定一次,就可以在增删改查等各种操作过程中起到作用,特别是在对象查询语句中,可以通过两两关联自动推导出多实体之间的关联关系,虽然推导出的结果未必是最优化的.

摘录自"Anders小明的Blog"
领域模型

概念上,一个领域模型和普通的符合面向对象原则的对象有声明区别:领域模型是业务意义上,承载了业务数据(可以认为所有领域模型是有状态对象),从本质上说它直接来源于现实世界,没有技术层次上的考虑,“符合面向对象原则的对象”是用面向对象方法分析得到的,是基于计算机领域技术的(这样的对象可以是无状态的);但反过来,符合面向对象的对象不一定反映业务领域的模型。

技术上,领域模型是指那些包含需要被透明持久化的属性,以及相关业务逻辑的POJO。一个领域模型包含了这些需要被持久化的业务数据,同时还包含了与之相关所有业务操作(即能操作所有属于本模型生命周期内的模型数据),并且有自己的继承体系。Martin Fowler认为有了这些就可以称为是一个领域模型,因此在其PoEAA中的ORM包含了一些不透明的持久化方案。我认为一个真正的领域模型需要一个透明持久化。

摘录自"Anders小明的Blog"
领域服务的运行模式

简单的说,业务处理将被细化成处理控制器和具体处理器。在这级别,处理对于请求的响应处理已知的有三种模式:

事件模式(Observer Pattern)、职责链模式(Chain of responsibility Pattern)以及数据流模式(Pipes and Filters Pattern)。这几个模式处理的各自不同的场景。其中数据流模式很适合需要处理大量数据的情况。

[该贴被oojdon于2009-11-03 21:34修改过]

         

2
oojdon
2009-11-03 22:05

技术问题

摘录
应用职责角色分层,必然涉及到两种对象,一种是用于展示信息的结构——VO(边界外通过编码方式使用的),一种是DAO对象。这两种职责角色对象,严格的说不算是业务设计需要关心的。然而却和系统开发息息相关。而业务设计中的变化导致相关的工作量却是巨大的。

VO对象是为了集成而存在的;其意义是:1. 保护系统的信息边界,提供一种结构可以使其它系统或者组件通过编码方式获取系统内信息的方式;2. 保护系统的事务边界,领域对象技术上携带着持久化信息,通过VO得以屏蔽。常见的VO对象存在于Web层和Domain层。

因此,VO对象的存在只是为了集成而存在,其是否存在的取决于两个方面1. 集成的设计结构;2. 框架的两个能力——对象路径访问能力以及事务边界管理。

Domain层VO对象,通常是用于不同领域组件间的交互,但随着架构的改进,集成代码独立存在而不再嵌入到组件内部,组件的边界问题保护不复存在;更进一步的是,框架提供自动化的接口适配映射能力的增强。因而VO对象失去存在的意义。

Web层VO对象,以SWF为例,早在SWF 1.x时代,框架就提供了丰富的对象路径访问能力,但其Web交互是典型的MVC2方式,事务边界在view的render前关闭,因而导致需要特定的VO对象来避免持久化信息问题;而SWF 2.x时代,view的render是在事务边界内,VO不再需要。

针对维护Dao对象而产生成本的一种解决方法是:代码生成。生成的策略分为两种环境,开发环境和生产环境。开发环境实时动态生成,可以采用动态代理机制;而生产环境要求性能,采用预编译生成能力。

另外Web层或者UI层,不需要额外的VO对象的另一个理由是:通常Web层的独立维护的成本大于其复用的价值。在开发中,Web层需要的信息都来自Domain层,这样容易出现Web层的VO对象和Domain对象结构一致,虽然这样便于学习和简化开发,但导致维护成本的提高,每当页面需要一个新的属性就需要改变太多的类,同时Domain对象设计容易限制于Web层,而实践中Web层的变化更多于Domain层。正确的路径是很好的维护Domain层,同时不维护Web层

[该贴被oojdon于2009-11-03 22:06修改过]

banq
2009-11-05 10:21

>一个领域模型包含了这些需要被持久化的业务数据,同时还包含了与之相关所有业务操作,并且有自己的继承体系。Martin Fowler认为有了这些就可以称为是一个领域模型。

非常认同这篇文章,其实现在基于JdonFramework 6.2的JiveJdon3.8更接近这种做法,让领域模型自己实现持久化,将修改 创建子贴等业务方法划入到ForumMessage中去完成,而且完全是基于内存实现的,性能也能提高。所以,大家可以发现,在这个论坛回复速度大大提高是一个说明。

这也说明,基于领域模型设计编程的架构,完美同时解决了软件扩展性和可伸缩性两个问题,而不是过去需要分别考虑,每次都考虑两次,很累哦,现在就累一次,扩展性和可伸缩性全部解决。

必须指出的是,很多人对MF这段理解以为使用Hibernate这样的ORM框架就可以,我不以为然,因为你使用JPA或Hibernate,还需要在模型之外实现事件动作xxx.save(model);而Jdon框架6.2提供了Domain Events,就可以在模型内部调用Hiberbate的xxx.save(model),Hibernate + Domain Events才是真正实现MF的这段领域模型定义。

以上只是个人观点和实践。

[该贴被banq于2009-11-05 10:25修改过]

oojdon
2009-11-05 12:32

2009年11月05日 10:21 "banq"的内容
基于领域模型设计编程的架构,完美同时解决了软件扩展性和可伸缩性两个问题,而不是过去需要分别考虑,每次都考虑两次,很累哦,现在就累一次,扩展性和可伸缩性全部解决。
我现在有一种彻底重构公司产品的冲动,这个过程应该非常的刺激,呵呵

[该贴被oojdon于2009-11-05 12:34修改过]

taochenpfj
2009-11-12 12:25

2009年11月05日 12:32 "oojdon"的内容
2009年11月05日 10:21 "banq"的言论基于领域模型设计编程的架构,完美同时解决了软件扩展性和可伸缩性两个问题,而不是过去需要分别考虑,每次都考虑两次,很累哦,现在就累一次,扩展性和可伸缩性全部解决。 我现在有一种彻底重构公司产品的冲动,这个过程应该非常的刺激,呵呵

[该贴被OOjdon于2009-11-05 12:34修改过]

哈哈,如果已经可以左右公司的领导层,那你已经可以动手了吧

我们公司也是有一大堆很混乱的系统,我也有此冲动啊!!!!

但是所谓“蚍蜉撼大树”,大树不动摇啊,哈哈哈哈哈

2Go 1 2 下一页