领域模型驱动设计(DDD)之模型提炼

         
banq 06-08-21

那么,一个正确的OOA/OOD/OOP步骤是什么呢?目前围绕模型驱动设计(MDD)的设计思想成为主流思想,MDA更是在MDD基础上提升和升华。下面让我们首先了解,如何使用领域驱动设计思想来分析设计一个软件系统。

http://www.jdon.com/mda/dddcase2.html

zyskm
2006-08-21 16:48

刚才发表不了,再试一下。

zyskm
2006-08-21 16:54

最近在看领域驱动设计方面的书,遇到一个问题,服务和其他类前的关系如何描述,不像实体之间或实体与值对象直接有着自然的关联关系。
下图是我对Issue tracking建的一个模型,问题和每次处理记录有着组合关系,“处理问题”这个类和其他类关系应该怎么描述。
打算用“处理问题”这个服务来获取用户对指定“问题”可进行的操作,一些对“问题”的其他操作也想封装在这里,现在感觉建立起这种关系很困难。
不知道是思路错了,还是关系没找清楚?

banq
2006-08-22 09:15

Domain Model和应用服务层分开,应用层:定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题,保持精练;不包括业务规则或知识,无业务情况的状态

领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。

说白了,就是动词和名词分开,名词用Model表达,动词用service或组件操作实现。

你的“问题处理”属于组件操作,在应用层,它指挥Model"问题"完成工作,所以不应该画在Domain Model的类图中。

问题处理是一个事件行为,必然导致一个结果,所以问题和问题处理结果之间关系是1:N的关系,类似本文中谈及的信息和信息细节的1:N关系。完全可以用本文的核心模型来表达。

我抽象出核心模型的目的就是因为很多初学者总是在建模时:迷惑那些关系,其实按照高内聚、低关联的设计原则,关联关系很少,尽量消灭,不要象分析数据库关系一样,将关系放在分析的核心重点。




zyskm
2006-08-24 10:26

多谢板桥上次的指点,这次把动作分解到应用层了,下图是调整后的模型。
还有一个问题就是,在1:n的情况下,比如User->Role用到了数组,在领域驱动设计那本书中是不建议用数组的。

2Go 1 2 下一页