DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
问题时间：2011/10/29
xj(35****79)2011-10-2911:32:02
潘老师，对于基础数据维护和报表在业务用例是不要体现的吧？ 潘加宇(704837756)23:02:29 这个问题问得很简单，却暴露出开发人员在业务建模中相当根本的思路错误，这个思路错误会导致我们的业务建模变成假的业务建模。 首先，这个问题本身问得不正确。"基础数据维护和报表"听起来像是你要开发的某个系统的功能（业务实体的责任），业务用例是一个组织对外提供的各种服务。一个组织提供的服务不会体现某个业务实体的责任。 那么，我猜想你问的问题是：在业务建模中，维护基础数据、出报表等业务流程中的活动应该放在哪个业务用例的下面描述？还是把它们单独归纳成一个业务用例？ 如果你的问题确实如我所说，那么回答如下；"维护基本数据、出报表"不能简单地视为同一种活动来处理。这样的思考方式已经是"以你的系统为中心组织的业务建模"了，估计就会想画出这样的错误图：
然后问：这个序列图属于什么业务用例？――这个思路已经有问题了。 业务建模描述业务用例以及业务用例的实现－－业务场景（业务流程），它是以价值中心组织的。"新增××"和"删除××"（其实这些名字已经起得不合适）,"出A 报表"和"出B 报表"不会无缘无故发生，很可能是以不同的频率，在不同的业务流程里面发生的，它们分别在不同的业务序列图中出现。 这也就是我们课上不断强调的，业务建模就象摄像机一路跟随实现业务用例的流程去拍摄，把拍到的故事如实画出来，来证明你的系统如果有这些责任，对实现业务用例是有帮助的。 开发人员常犯的错误就是把自己的系统看得比天还大，把摄像机放自己的系统的旁边，意淫一些功能，把这些功能加起来就变成"业务流程"了。这样的业务建模实际上跟拍脑袋直接画该系统的系统用例图没有区别，毫无价值。
刘伟(55*****22)23:11:11 再问一下，按上面的解释，例如对于由业务人员从管理界面上进行的数据维护，出报表操作等2个场景的操作，是否就可分为数据CRUD，出报表等2 个用例？ 潘加宇(704837756)6:39:55 按照业务流程来映射，是几个就是几个 xj(35****79)21:19:12 根据以前的培训是不放在业务用例中，但是这是系统功能，这些功能是在系统用例中引入么？如何做到自然的引入？ 潘加宇(704837756)21:29:28 业务用例－－>业务序列图－－>系统用例 自然地从业务流程推导出来，你的系统提供这些功能肯定是为了改进现状的某些业务流程嘛 xj(35****79)21:31:01 但是像基础数据在业务序列图中就无法导出来 和业务有关的系统用例是自然可以导出的 潘加宇(704837756)21:36:37 你的系统不存在之前确实不存在的工作（出**报表，添加商品类别等有领域意义的用例并不属于这个范围），确实没有办法从现状业务流程导出，这些功能用CRUD 来打扫垃圾即可。
这些用例一般都是：系统管理员-->管理用户；系统管理员--配置系统参数...等。
这些用例也会发生在改进后的某些业务流程中，系统管理员也不会无缘无故创建用户，配置参数
xj(35****79)21:38:16 对对，就是这些账户管理、用户管理等
[19:30上课]10月24-28日晚剔除伪创新的领域驱动设计-网络公开课
[新增架构师专用集锦AD-001]28套UML EA和StarUML的建模示范视频-全程字幕（20221006更新）
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信：umlchina2
