办公系统UML

提示一下：四色图用错了

还有我没有看到DDD的影子……

感谢您的回复，我再去好好研究研究

111
[该贴被OweJDao于2011-03-10 14:25修改过]

项目日志和工作日志有什么内在关系？是表象不同还是内在不同？

从用例看，可以分几个子领域 日志系统 文件审批系统，公共和消息通讯系统。

不知是否合适？

先从日志模块分析，类图分析的不知道完不完整，不知道能不能看到DDD的影子

DDD的影子就是从实体根，找领域边界，这样就能找到领域模型，我在新图中没有发现核心实体根，你的工作日记和时间日记关系太含糊，最不愿意的是首先看到日记服务，我最愿意看到的是实体聚合边界和根实体和其值对象，你能告诉我或者用<<>>方言在图中表达一下吗？

我觉得楼主对业务的理解有点问题。就是对每天工作日志和时间段日志的混淆，每天工作日志对象应该是时间段日志对象的聚合跟，时间段日志的增删改查都应该由每天工作日志对象负责，每天工作日志负责保持聚合跟内的不变形（比如，每次增加的时间段日志是否与其他的时间段日志有交叉，时间是否是今天，等等）。还有日志是否在被查看这个状态。这个应该属于每天工作日志而不是时间段日志，因为领导虽然是查看某个时间段的日志，但是也是以查看一天的日志为基础的，如果某一天的日志被查看，这一天的所有时间段都是不能编辑的。至于项目日志到底跟工作日志有什么联系要看项目日志到底有多复杂。

先感谢一下banq,和各位大哥的指点，小弟笨,整理了下，新的图如下，

看来你是想画四色原型，缺一个重要的元素，角色Role，现在离DDD还比较远。

不敢妄论什么DDD。不过，能明确感觉到的是，楼主需求分析开始阶段出现了问题。涉众、愿景、参与者、系统边界，这些基本上都是需求分析之前要定下来的东西。而从楼主的用例图上看，没有这些重要元素的体现。
问题二，用例图只是个图，光看图是看不出业务流程来的。而用例的重点我认为是场景，包括成功和失败的场景。在有场景的用例之后，用例图才能发挥功效，达到一图顶万言的效果。
问题三，场景从何而来？从现实世界中来，从涉众中来。这些场景获得之后，还需要需求分析师提炼，抽象化。通过抽象化过程之后，我们就能看出哪些东西可以成为一个完整用例（注意：用例本身就是一个有前提，有过程，有结果的完整集合）。而看楼主的用例，感觉很随意，很多用例可能只是场景中的一个步骤。
在这里，我认为，OO的精髓——抽象化，在业务分析阶段就要开始了。只有这样我们才能抓住主要问题不放，而次要问题则是在不断的进行成本、风险评估之后，迭代的去解决，就是回过头来再需求—》分析-》设计。

愚以为，这般过程下来，有无DDD又何妨？：）
[该贴被showerxp于2011-03-13 09:59修改过]
[该贴被showerxp于2011-03-13 10:05修改过]

说不敢妄论DDD，又妄论DDD了。
好像banq大爷说过，不确定，反正鄙人就是这么理解的——DDD就是把设计模式概念的运用从OO设计过程中提前到OO分析过程中。似乎是用一种模式化的过程，去提炼需求，从而得到分析类。

在这里，我引用一下统一建模过程的概念——以用例为驱动、以架构为中心的、迭代增量的开发过程框架。领悟到——用例（也就是需求分析）作为基本元素的OO开发过程，也就能自上而下的领悟DDD。如果是反过来，就DDD概念而不抛弃原先的非OO思想去“实践”DDD，那么总是距离DDD渐行渐远。

我给一个设计方案，献丑一下。

非常感谢showerxp大哥的讨论，和图形方案; 我再好好想想，回头把新的方案贴上来再指教

看下一页了
[该贴被wuxiaoyong于2011-03-18 11:44修改过]