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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ding!

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

是的，关联处理不好，就导致复杂，这个我深有体会。

所以，我在本文中提炼出一张简标图，如果能够将一个需求分析到这个图或此图的组合，实现起来就是一路通畅了。