首页 新闻 搜索 专区 学院

DDD实施,领域建模遇上的疑问。

0
悬赏园豆:10 [已解决问题] 解决于 2010-08-18 12:17

最后10分,希望可以释疑。

背景:最近不断反思自己的设计为什么越精进越和传统3层有所抵触,经过仔细反思,不断地search,发现,正在接近一种设计方式DDD,传统的3层(表现层、业务逻辑层、数据访问层)而DDD中分4层(表现层、应用层、领域层、基础层)。这段时间体会最深的是应用层,一个事件分流作用,有点像一个任务调配者的。

问题:领域层,究竟如何根据建模?举个简单需求,做一个账单登记模块。抛开数据库,从领域出发,用户具有新建账单,编辑账单等行为,也是比较直观的,但那些展示数据的功能又如何划分到领域模型中呢?例如常见的有账单的明细展示,账单头显示,这些功能不知道如何按模型划分,高手请指教!

bugfly的主页 bugfly | 初学一级 | 园豆:10
提问于:2010-08-17 17:19
< >
分享
最佳答案
0

领域层 根据业务逻辑、业务需求进行建模,把业务逻辑映射成一个个对象直接的交互、以及数据的传输DTO(Data Transfer Object );

拿你举的例来说,就有 NewBill(),EditBill(),ReviewBillDetails() 等操作,DTO 就有 BillEntity,BillDetailEntity,等;DDD 一个重要特征就是 DTO 的出现DTO 是根据领域(业务逻辑)来划分的, 而不是数据表 ,DTO 不跟 表一一对应、虽然大部分简单的没有业务操作的基础数据表也可以当成DTO,但是他们的划分依据完全不同。

收获园豆:10
HUHU慈悲 | 大侠五级 |园豆:9973 | 2010-08-17 18:05
有点感觉,不过有两点疑问。 1. NewBill(),EditBill(),ReviewBillDetails() 这些操作,要有一个领域对象去包含、组织它们,而这些归类一定就合适吗?这些名词如此直观的功能确实可以很快地归类,而那些没名字概念的功能,例如常见的有各种各样的数据展示操作,它们不一定有一个很好的领域名词,而这些功能又该如何归类呢?归类没有一个明确的规则功能重复这些情况会频繁出现。这里引申的问题就是,如何根据需求驱动出准确的领域模型。 2.DTO,我有点不明白的是,DTO在我看来是一样不稳定的东西,今天需求变了,UI的数据形式变了,那领域层某些模块也要变吧?如此影响,怎么不直接用稳定的PO对象来传输数据? 希望大哥说多一点,小弟实在很多疑问。
bugfly | 园豆:10 (初学一级) | 2010-08-18 09:02
大哥,刚顿悟出一个设计概念,你帮我看看是否正确。 数据访问层:PO(表实体对象)、领域层:DTO(领域实体对象)、UI层+应用层:VO(视图实体对象)。这样的好处是连数据的传输方式都隔离了,各层的职责更明确了,不存在交叉感言的情况,视图层再怎么变化都不会影响到领域层,所有数据判断也放在应用层,哈哈,我感觉这个思路非常清晰,不知道对否。
bugfly | 园豆:10 (初学一级) | 2010-08-18 09:50
不知道你对 UML 了解多少。里面有个很好的概念就是“用例”和“类图”。用例(Use Case)是一种描述系统需求的方法,用例建模就是描述系统需求的过程。用例可以对系统功能进行个大体的划分、分成多个相互交互的模块,以及每个模块的功能。而类图则是表示参与各个模块业务逻辑处理的对象。类图中的属性、方法则表示每个对象的状态和行为。一个类具有什么样的属性、方法是根据对应的用例来划分、即这个用例是做什么的?还是那上面的例子来说吧:上面的都是针对账单的操作、即 账单管理 这个功能模块,就可以得出" 账单" 这个领域对象; 有 新增账单、修改账单、查看账单明细……等用例对于新增账单这个用例来说,可能要验证操作人是否允许新增账单、是否要审核账单等等步骤,这里就有个问题就是“验证”、“审核”操作应该挂接在哪个类上面。这就要看,执行这些操作的主体是谁。就是看这些操作是由谁来做,如果是系统管理员,那就是系统管理员要提供 验证 审核 操作供 账单这个领域对象来调用。至于你说的“2.DTO,我有点不明白的是,DTO在我看来是一样不稳定的东西,今天需求变了,UI的数据形式变了,那领域层某些模块也要变吧?如此影响,怎么不直接用稳定的PO对象来传输数据?”:DTO 这种对象出现的作用就是供 领域对象之间、以及业务层与表现层之间的数据传递。只要业务逻辑没有变化,DTO 如果之前已经分析好了, 就不应该会有什么变化,但如果需求变了、业务逻辑变化了,那DTO 肯定会变化的。要不DTO 怎么适应领域对象呢?PO 这种对象在领域对象的功能不复杂、只有简单的CRUD 的时候是完全可以代替DTO 的。关键是在复杂的业务逻辑中,PO满足不了了,因为在复杂的业务逻辑中,DTO 与PO 不一定是一一对应的关系,而往往是一对多的关系。像你说的,需求变了, 那系统肯定跟着变、但 DTO 实际上是一种解耦的方式、表现层、逻辑层的契约就是DTO,只要这个契约不变, 你UI再怎么调整,逻辑层都不受影响的;同样逻辑层与数据访问层可以用PO来做契约,这样只要逻辑层不改变、表示层就不会受影响,不管数据访问层怎么调整,这样三层就两两解耦了。但都用 PO 的话,就相当于 表现层、逻辑层、数据访问层;三层都耦合在一起了。这个在设计上也是忌讳的。
HUHU慈悲 | 园豆:9973 (大侠五级) | 2010-08-18 10:32
嗯, 对没错、就是层层解耦了。
HUHU慈悲 | 园豆:9973 (大侠五级) | 2010-08-18 10:33
大哥,你的评论够我品味过中奥妙了,感谢帮忙。谢谢你的热心。
bugfly | 园豆:10 (初学一级) | 2010-08-18 12:17
其他回答(1)
0

莫非只有大项目这么纠结。只是拿到需求,代码实现。

Astar | 园豆:40805 (高人七级) | 2010-08-17 17:27
倒不是大项目要这样,为了更好的维护和扩展,甚至细化到每个人的分工
支持(0) 反对(0) bugfly | 园豆:10 (初学一级) | 2010-08-17 17:39
并不偏离你的问题,只是有时候越敏捷越麻烦。
支持(0) 反对(0) Astar | 园豆:40805 (高人七级) | 2010-08-17 17:42
一个项目的设计大体就两种出发方式:数据库建模、领域建模。作为一个Designer最关键是驱动出一个针对需求的设计,而业务这一块正是最关键的,如果设计都没做好,也谈不上如何敏捷了,对于胸有成竹的功能点,当然可以手到拿来,而那些模糊的功能,根本敏捷不起来,也是我问这个问题的起因,到了业务复杂这块,发现之前驱动出来的接口没对上需求,有点补洞的感觉,哎。
支持(0) 反对(0) bugfly | 园豆:10 (初学一级) | 2010-08-18 09:10
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册