办公系统UML

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

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

不知是否合适？

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

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

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

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