需求分析与企业信息架构

<<DDD>>看着看着，对几个问题渐渐迷惑起来，Domain的分析过程和UseCase的分析过程怎么结合与区别？如何更好的把两者进行区别？Domain Model的建立该归为需求分析过程还是设计过程？分析人员和用户代表是否要拿着UC图交流系统功能,拿着DM图交流业务逻辑和关系?(如果用户代表对这些图感兴趣或者有技术背景的话)

从steven的一份ppt中看到这么一段描述

企业信息架构

企业信息架构是将企业业务实体抽象成为信息对象，将企业的业务运作模式抽象成为信息对象的属性和方法，建立面向对象的企业信息模型。企业信息架构实现从业务模式向信息模型的转变，业务需求向信息功能的映射，企业基础数据向企业信息的抽象。
企业信息架构对企业业务进行建模，它能独立于技术的发展和变化，并能帮助项目中业务人员和技术人员之间的沟通。

企业信息架构模型
业务功能模型
 通过层次化的用例（Use Case）模型描述企业范围内各种应用（如电子商务，客户服务，B2B STP整合）的功能需求。
业务过程模型
 功能模型通过逐级分解的过程模型（业务过程，子过程，活动）细化描述，并且过程模型也包括了输入/输出的定义。
业务对象模型
 业务对象模型描述了企业相关的实体和关系，并以面向对象的方式封装不同实体的角色和职责。

有点感触，企业级系统中，需求分析的过程应该是将企业业务模型到企业信息模型的一个Map的过程。同用户的沟通，可能同时获取到UseCase，WorkFlow，DomainLogic的相关内容（或者说每次沟通有不同的侧重，但免不了涉及到其它方面），分析人员有必要将沟通的结果对应到不同的模型上面去的。另外上诉三个模型间也有着相当的关联的（废话？），比方说对象间是双相关联还是单向关联很可能就是由UseCase决定的。 另外模型的建立有可能是独立于系统的建立的...