3.4 分析业务用例场景
分别针对上节中业务用例视图中的每一个用例，分析该业务用例在实际工作中是如何做的，一般使用业务活动图来表述业务场景。在这个阶段，有几点需要特别注意的地方：
1、关注参与业务用例的各个参与者是如何协同的，如一个简化的用户开户的流程就是填写营业员提交开户订单-》主管审批订单-》施工人员履行订单；
2、对一个业务用例，如果有不同的实现路径，需要做不同的场景分析。例如，用户订购产品，分网上订购和营业厅订购这两种场景，两个场景大不相同；
3、场景的步骤粒度：用户的一个完整操作目的，如用户开户，则用户填写订单是一个步骤，而不用细化到用户取单、拿笔填单等；
3.5 产生业务对象模型
针对每个业务用例，根据业务用例场景，分析该用例中涉及的业务实体，并绘制业务对象模型图。
3.6 产生业务用例实现视图
业务用例实现指业务用例的一种实现路径，一个业务用例实现对应着一个业务用例场景。业务用例实现视图是表述业务用例实现的视图。
3.7 分析业务用例实现场景
业务用例实现场景着重描述如何通过人机交互来完成业务，是业务用例场景的具体化。一般用活动图来表述人机交互流程。这里每个步骤的粒度是人与系统或系统与人的一次交互。
3.8 领域建模
领域模型是描述特定问题域的对象及其相互关系。领域模型对业务对象做了进一步的精化。领域建模的步骤如下：
1、确定问题域：如CRM中的客户模型比较关键，我们决定对其进行领域建模，则需要将设计客户业务实体的用例全部识别出来；
2、领域建模：逐一分析涉及到操作客户模型的业务用例场景，识别领域对象以及对象之间的关系；
3、验证领域模型：使用序列图作为工具，基于领域模型来编排实现各业务场景，如果能实现，证明领域模型ok。
领域对象跟业务对象有区别，我认为，业务对象不是领域对象。业务对象来自于业务用例，是业务中客观存在的，而领域对象是对业务对象做进一步抽象、精化后的结果，是人对业务的主观认识，这就是为什么不同厂商的产品模型会不一样的原因，而且并不是所有的领域对象都是根据业务对象分析而来的。比如，某CRM产品面向全球市场，可定制能力是关键，为提升可定制性，需要构建一个快速开发框架，这个快速开发框架也是软件系统的一部分，也是有领域模型的，但是它的领域模型跟业务对象没半点关系。
3.9 产生逻辑架构草稿
通过上述步骤，我们已经有了部分领域模型，针对每一个可直接映射到业务对象一级的领域对象，可规划相应的业务模块，如有开户订单，那么可以有订单管理，有客户管理等。业务模块的划分粒度可依据大概的工作量而定，保证最低级别的业务模块的工作量是大致均匀的。这仅仅是一个建议，可以根据项目的实际情况决定。
基于上述的成果，我们还只能产出一个逻辑架构的草稿，因为我们还没有分析质量属性，后续对质量属性做设计的时候，还有可能会引入新的模块。比如要让业务流程可快速编排、定制，我们希望引入工作流，那么逻辑架构中也要引入一个工作流模块。
待续。。。