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

在线150人

J道首页 |

论坛首页 |

培训咨询 |

开源框架 |

精华 |

查搜 |

登陆 |

首页 » 论坛 » 项目工程开发经验谈

上一主题

返回主题列表

下一主题

这个主题共有 8 回复／ 1 页 [ ]

banq

发表文章: 8929
注册时间: 2002年08月03日 17:08

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

发表: 2006年08月21日 13:38

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

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

zyskm

发表文章: 5
注册时间: 2006年08月21日 16:27

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

发表: 2006年08月21日 16:48

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

zyskm

发表文章: 5
注册时间: 2006年08月21日 16:27

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

发表: 2006年08月21日 16:54

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

banq

发表文章: 8929
注册时间: 2002年08月03日 17:08

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

发表: 2006年08月22日 09:15

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

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

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

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

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

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

zyskm

发表文章: 5
注册时间: 2006年08月21日 16:27

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

发表: 2006年08月24日 10:26

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

banq

发表文章: 8929
注册时间: 2002年08月03日 17:08

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

发表: 2006年08月25日 16:43

》还有一个问题就是，在1:n的情况下，比如User->Role用到了数组
权限ACL等问题属于和业务领域分离的，现在有专门的框架和产品来设计，可以做成通用的，一般可以不在领域模型图中表现。

1:N实现当然不用数组了，我N多年前就反对用数组，应该用集合概念替代数组，使用数组容易导致非对象化编程，数组里放的都是原始类型啊。

你这个图虽然完成，非常不错，已经考虑进去很多新的领域对象。

谈一下缺点，千万不要介意，个人感觉有些象太阳系星图，一般出现这种情况表示分析没有到位，关联关系太多，逐个检查你的关联，能够去除就去除，千万不要以为画出一个纵横交错的图会让人感觉高深，其实，建模就是将复杂问题简单化。

yuansu2006

发表文章: 8
注册时间: 2006年08月24日 16:27

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

发表: 2006年08月25日 17:40

Ding!

zyskm

发表文章: 5
注册时间: 2006年08月21日 16:27

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

发表: 2006年08月28日 10:19

呵呵，板桥说的有道理，这张图画出来后自己看着也觉得牵扯太多，不都画上的话又觉得有些关系没表达。
周末在家又看了看《领域驱动设计》重新认识了一下，有些关系虽然存在但不一定都要在这张图中表达，比如板桥说的用户－权限这部分，领域模型只专注于特定部分，其他另画一张图来表达了。
另外把斜线都拉直了，看着也清晰了许多。
要说也是挺简单的事，一开始画的时候就没想到。