[CTO札记]业务架构

软件的业务架构（Business Architecture, BA）是个较新的词，可以说是（需要软件化的）业务逐渐复杂的结果。业务复杂到一定规模后，必须对其进行梳理与设计，结果就是BA。

BA通常的工作就是：识别模块、划分功能、厘定（他们间）关系。

一、模块结构图

复杂的系统，通常用模块结构图来表达顶层架构。

<a href="http://davyyew.blogbus.com/files/20090901120343.png"></a>

上面的例子说明了将构建系统将由3个子系统组成，并与二个已有的外部系统打交道。

二、细化的模块结构图（带接口）

上面的例子比较复杂，我们有必要作出小小的细化，来说明子系统间如何连接。

我们在开发软件时，对于接口，比较模块化的处理方式是将2个系统间接口处理部分逻辑上独立出来，形成Caller与Callee。

做业务架构，可以采取同样的方式。在上图中，多处连接我使用用Service与Adapter来表达Callee与Caller。这种一致化的表达，可以在未来，直接映射到软件逻辑架构。

三、功能分布表（Feature Distribution Table）

通常的业务分析结果，是得到一个功能列表（Feature List）。

但是对于一个大型系统，功能(Feature)将会非常多；并且可能有一定的传递性（即某功能F可能在模块M1、M2、M3中都有体现）。此时使用功能分布表可能更利于：

》功能识别的完整性

》识别出可重用功能

》分析功能转移的可行性（功能从模块A移到模块B）

下面是针对上述模块结构图的一个示例：

本文转自DavyYew 51CTO博客，原文链接：http://blog.51cto.com/davyyew/241245 ，如需转载请自行联系原作者