DDD实施，领域建模遇上的疑问。
0
悬赏园豆：10
[已解决问题]
解决于 2010-08-18 12:17
最后10分，希望可以释疑。
背景：最近不断反思自己的设计为什么越精进越和传统3层有所抵触，经过仔细反思，不断地search，发现，正在接近一种设计方式DDD，传统的3层（表现层、业务逻辑层、数据访问层）而DDD中分4层（表现层、应用层、领域层、基础层）。这段时间体会最深的是应用层，一个事件分流作用，有点像一个任务调配者的。
问题：领域层，究竟如何根据建模？举个简单需求，做一个账单登记模块。抛开数据库，从领域出发，用户具有新建账单，编辑账单等行为，也是比较直观的，但那些展示数据的功能又如何划分到领域模型中呢？例如常见的有账单的明细展示，账单头显示，这些功能不知道如何按模型划分，高手请指教！
最佳答案
0
领域层 根据业务逻辑、业务需求进行建模，把业务逻辑映射成一个个对象直接的交互、以及数据的传输DTO(Data Transfer Object );
拿你举的例来说，就有 NewBill(),EditBill(),ReviewBillDetails() 等操作，DTO 就有 BillEntity,BillDetailEntity,等;DDD 一个重要特征就是 DTO 的出现，DTO 是根据领域（业务逻辑）来划分的， 而不是数据表 ，DTO 不跟 表一一对应、虽然大部分简单的没有业务操作的基础数据表也可以当成DTO，但是他们的划分依据完全不同。
收获园豆：10
有点感觉，不过有两点疑问。
1. NewBill(),EditBill(),ReviewBillDetails() 这些操作，要有一个领域对象去包含、组织它们，而这些归类一定就合适吗？这些名词如此直观的功能确实可以很快地归类，而那些没名字概念的功能，例如常见的有各种各样的数据展示操作，它们不一定有一个很好的领域名词，而这些功能又该如何归类呢?归类没有一个明确的规则功能重复这些情况会频繁出现。这里引申的问题就是，如何根据需求驱动出准确的领域模型。
2.DTO,我有点不明白的是，DTO在我看来是一样不稳定的东西，今天需求变了，UI的数据形式变了，那领域层某些模块也要变吧？如此影响，怎么不直接用稳定的PO对象来传输数据？
希望大哥说多一点，小弟实在很多疑问。
大哥，刚顿悟出一个设计概念，你帮我看看是否正确。
数据访问层：PO（表实体对象）、领域层：DTO(领域实体对象)、UI层+应用层：VO（视图实体对象）。这样的好处是连数据的传输方式都隔离了，各层的职责更明确了，不存在交叉感言的情况，视图层再怎么变化都不会影响到领域层，所有数据判断也放在应用层，哈哈，我感觉这个思路非常清晰，不知道对否。
不知道你对 UML 了解多少。里面有个很好的概念就是“用例”和“类图”。用例(Use Case)是一种描述系统需求的方法，用例建模就是描述系统需求的过程。用例可以对系统功能进行个大体的划分、分成多个相互交互的模块，以及每个模块的功能。而类图则是表示参与各个模块业务逻辑处理的对象。类图中的属性、方法则表示每个对象的状态和行为。一个类具有什么样的属性、方法是根据对应的用例来划分、即这个用例是做什么的？还是那上面的例子来说吧：上面的都是针对账单的操作、即 账单管理 这个功能模块，就可以得出" 账单" 这个领域对象； 有 新增账单、修改账单、查看账单明细……等用例对于新增账单这个用例来说，可能要验证操作人是否允许新增账单、是否要审核账单等等步骤，这里就有个问题就是“验证”、“审核”操作应该挂接在哪个类上面。这就要看，执行这些操作的主体是谁。就是看这些操作是由谁来做，如果是系统管理员，那就是系统管理员要提供 验证 审核 操作供 账单这个领域对象来调用。至于你说的“2.DTO,我有点不明白的是，DTO在我看来是一样不稳定的东西，今天需求变了，UI的数据形式变了，那领域层某些模块也要变吧？如此影响，怎么不直接用稳定的PO对象来传输数据？”:DTO 这种对象出现的作用就是供 领域对象之间、以及业务层与表现层之间的数据传递。只要业务逻辑没有变化，DTO 如果之前已经分析好了， 就不应该会有什么变化，但如果需求变了、业务逻辑变化了，那DTO 肯定会变化的。要不DTO 怎么适应领域对象呢？PO 这种对象在领域对象的功能不复杂、只有简单的CRUD 的时候是完全可以代替DTO 的。关键是在复杂的业务逻辑中，PO满足不了了，因为在复杂的业务逻辑中，DTO 与PO 不一定是一一对应的关系，而往往是一对多的关系。像你说的，需求变了， 那系统肯定跟着变、但 DTO 实际上是一种解耦的方式、表现层、逻辑层的契约就是DTO，只要这个契约不变， 你UI再怎么调整，逻辑层都不受影响的；同样逻辑层与数据访问层可以用PO来做契约，这样只要逻辑层不改变、表示层就不会受影响，不管数据访问层怎么调整，这样三层就两两解耦了。但都用 PO 的话，就相当于 表现层、逻辑层、数据访问层；三层都耦合在一起了。这个在设计上也是忌讳的。
嗯， 对没错、就是层层解耦了。
大哥，你的评论够我品味过中奥妙了，感谢帮忙。谢谢你的热心。
其他回答(1)
0
莫非只有大项目这么纠结。只是拿到需求，代码实现。
倒不是大项目要这样，为了更好的维护和扩展，甚至细化到每个人的分工
并不偏离你的问题，只是有时候越敏捷越麻烦。
一个项目的设计大体就两种出发方式：数据库建模、领域建模。作为一个Designer最关键是驱动出一个针对需求的设计，而业务这一块正是最关键的，如果设计都没做好，也谈不上如何敏捷了，对于胸有成竹的功能点，当然可以手到拿来，而那些模糊的功能，根本敏捷不起来，也是我问这个问题的起因，到了业务复杂这块，发现之前驱动出来的接口没对上需求，有点补洞的感觉，哎。
