企业架构思想在软件架构设计中的引入

很多时候我们在谈企业架构的时候都是正对跨流程，跨业务和跨应用系统的总体规划和分析，企业架构核心好处就是真正体现业务驱动IT，将业务和IT能够真正的匹配起来思考整个企业层面的架构问题。而很多时候我们谈软件架构的时候仅从软件实现层面来考虑问题，针对一个业务系统的开发，我们有业务建模和软件架构，但是这两个却进行了分离而缺少了系统性的思考，所以原来我们喜欢用系统分析师这个词来综合业务分析师和软件架构师两个岗位的工作。

对于企业架构思想融入到软件架构中，即真正对软件架构层面的工作进一步整合，减少在系统分析过程中从现实业务层面来抽象IT层面的脱节。改变传统软件架构仅仅考虑实现层面和技术层面的问题。对于引入方法和具体内容，还是从软件架构的一些核心内容来谈。

对于传统的RUP方法强调用例驱动，架构为核心。对于用例驱动在架构层面首先有全局的用例模型，很多时候我们没有考虑如何真正建立全局用例模型，而结合业务建模可以看到仍然是流程分析，子流程，业务功能逐级展开后形成全局用例模型，那么全局用例模型就不简单是用例图能够涵盖的，全局用例模型通过流程驱动真正融为一个整体。

再回来看逻辑视图，对于逻辑视图现在我们更喜欢基于领域模型的方式来分析逻辑视图，对于逻辑视图建议仍然是不要一下进入到具体的类图和类关系图层面，而更加重要的还是理清楚核心的业务对象模型和对象间依赖，关联关系。可以从用例建模中识别核心业务对象并进行对象建模，形成核心的逻辑视图。

用例视图偏动态的流程和业务功能，而逻辑视图偏静态的业务对象和数据模型。这是架构设计关注的两个核心内容，在这个完成后带来另外一个问题即组件如何划分？可以讲我们现在进行架构设计划分组件的时候往往并没有深入的去考虑这个问题，只是给出高内聚松耦合的大原则。这也是在模块划分我一直考虑需要引入传统的类似CRUD矩阵分析等方法的原因。

对于组件的划分，从原来的流程和数据两条线再来分析组件划分方法可以看到，可以根据大的业务流程阶段，子流程来划分组件，不通的阶段或子流程划分为不同的组件，如供应商协同，招投标，合同管理，采购管理等。也可以根据核心的业务对象来划分不同的组件，如采购订单对应采购管理，合同对应合同管理，请购单对应请购管理等。不论是哪种方法最终要达到的目的都是减少组件间的交互和接口，很多时候组件划分工作不是一次就完成的而是需要通过反复的迭代，比如为了减少集成接口可能将某个业务功能从组件A移动到组件B等。对于组件划分的分析包括了组件划分完成后组件和组件间的接口和集成分析，组件和数据间的关系和CRUD分析，系统级流程在多组件间的协同和交互模拟等。而这可以看到正是开发视图和进程视图要解决的问题。

前面这些都分析完成后，自然引入集成架构和集成视图的概念，即组件划分完成后需要考虑组件间有哪些接口，接口识别仍然是前面跨组件系统分析交互点，接口识别清楚后可以画出完整的系统内组件集成架构。跨组件业务协同流程等。这些内容仍然都是架构设计的核心，否则分解到每个组件设计的时候出现只见树木不见森林的情况。不清楚组件在整个系统中的具体位置。

这些都清楚后才应该过渡到物理视图层面，物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

从前面整个分析设计可以看到基本没有谈到技术框架，架构分层模型等内容，也再一次说明了架构设计重点在功能性架构和核心领域逻辑，而不是一开始就陷入到分层技术架构模型中。只有把前面的内容都搞清楚了才能给更好的考虑如何建立业务系统本身需要依赖的技术平台。

   青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密