领域设计 实践疑惑

项目:合格供应方管理
企业内部的供应方需要通过该企业的合格供应方申请审批流程后,才能成为合格的供应方,才能进行后续的贸易活动。合格供应方申请可以由企业内部员工或者是合格供应方(同一平台上的)自己提交申请;企业内部通过已经建立好的评估方案对该申请进行评估考核;最后由企业的决策层审批。
模块关系图:

建模思路:
实体:
评估方案、申请单、供应商、产品信息、审批信息、评审信息(上图暂未给出)
因为这些都是需要跟踪的。

值对象:
评估分类、评估项目

疑惑:
建立类图时,申请单与审批、评审信息之间的关系如何表示?申请单中有审批、评审的集合?审批、评审中有申请的引用?还是前面两者都做,用双向关联?

望各位发表一下高见。
[该贴被tqb于2008-12-04 14:58修改过]
[该贴被tqb于2008-12-04 15:11修改过]
[该贴被tqb于2008-12-04 15:13修改过]

呵呵,错了

申请单与审批、评审信息之间根本就没有直接的联系,他们是被第三者关联起来的。“申请”是一个整体,“申请单”“评审信息”都是它的子元素。

看你的图觉得还是在以数据为核心思考。

只是没一步抽象出“申请”这种抽象的主体,因为只关注了表面的名词吧,这些词更实在点,看得见摸得着。我在这方面也很弱,经常不能一下子发现这样的主体,直到客户老是向我说这些词我才感觉自己有问题。

banq所说的问题就是在这里,因为太过于关注表面而忽略了其中的实质。

那正确的uml应该怎么画出来?

可以试试吗?

我并不熟悉他的业务,只能是按照他的描述做一点点的分析。所以没办法把UML的结构画出来。

IceQi 分析有道理,其实四色图很容易帮助我们搞清楚哪些是活动,哪些是活动输入元素,哪些又是活动的结果,我们不能将输入元素和输出结构进行直接关联耦合,他们只要通过活动服务之类重要业务动作后才有意义。如果忽略中间活动,只考虑静态数据,就容易犯数据库思维的问题。因为数据库分析就是只看静态数据,不看行为的。

谢谢IceQi、freebox、banQ分析!!!!

我举例的这个是实际项目中用到的,需求也就是我前面所描述的。最近在看《领域驱动设计--软件核心复杂性应对之道》和《领域驱动设计精简版-InfoQ.pdf》,想在实际工作中应用。
论坛中各位高人,可以把它当作一个新的东西来做,根据自己的想法、设计思路,把相应的图画出来,大家一起讨论和学习(绝对不是另有所途,只是想结合实际,这样理解会深刻些)

hello tqb
有一个问题需要说明一下,类图或者系统结构不是设计出来的,所有的设计人员只能是用软件的方式描述现实中的最真实的状态,做到这一点就对了,做不到就错了。

在不了解你的核心业务的情况下没有人可以画出类图来,也不能描述一个真正合适系统结构。我们上面说的都是理论上分析出来的,很难符合你的实际情况。还是你把问题分解一下吧,我们才有分析的基础。

那"申请"应该是description还是MI呢

偶不懂4色图。。。。

请高人回复一下

迷糊了