[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 ，如需轉載請自行聯系原作者