筆者幾年前曾參與過一套網路銀行的系統建設以及後續這套系統在信用、雲服務、保險、**、支付等領域的復用，使用了ifw模型的變體。當時僅僅是根據架構師的設計進行編碼、測試和交付以及後續的維護，沒有對這套模型進行系統化的總結，心中總是有點缺失。這麼多年過去，藉著在組內分享的機會，系統地整理一下這塊的知識，希望對以後的設計建模能有所幫助。
限於筆者水平，同時ifw模型實際上是非常複雜（以至於對於專業的諮詢公司來說，這套模型的諮詢+分析+落地方案設計費用通常在百萬到千萬級別），短短的一篇博文僅僅是管中窺豹，而且由於理解偏差也會有錯誤的之處，因此僅作參考。
ifw是ibm的information framework縮寫，旨在描述銀行業務，可以看做領域內技術和業務溝通的橋梁。ifw是一套zachman framework的變體，後者最經典之處在於5w1h維度下對於6個概念的劃分：
這裡對於zachman framework不展開介紹，保持聚焦於ifw本身，其所應用的產品很多：
保險業其他
整個業務模型框架分為以下幾個板塊：
銀行資料倉儲
ifw整合模型
ifw流程模型
其中「ifw基礎模型」如其命名，是基礎中的基礎。個人理解，「工作流模型」是指工作流中的各個實體，如節點、跳轉條件等，「流程模型」指的是抽象或具體的某個流程。
ifw將金融資訊分解為九大資料概念，所有的金融業務中都可以套用到其中。具體的細節可能有差異，我一共參考了兩份資料，下面一共列了11項，其中前7項是公有的，
第89份是我所參與專案中使用的，1011項是另乙份資料中的。其中「渠道」和「業務方向」有重合之處。
這部分是我實踐中接觸最多的地方，也是對建模最有幫助的。
概念簡稱
說明舉例
參與者ip
業務往來、資訊互動中關聯的各方
個人、機構、櫃員、平台商、委託方、**人
位置lo
條件cd
描述業務開展時需要的前提條件、資格標準、要求、限制、服務引數
需年滿18歲、利率、**、週期
產品pd
提供給客戶用以換取任何形式利潤或收益的產品和服務
活期存款、貨幣**、人身險、實體商品
合約ar
描述或兩個或兩個人、團體、組織等潛在或實際的協議，申明了權利或/和義務
服務協議、產品協議
資源項ri
各參與者擁有、需要管理和使用的物品項
身份證、借條、房產、通行證
事件ev
參與者之間、參與者與系統、系統與系統互動的行為與資料
交易事件、存款事件、收費事件
賬戶ac
記錄及監控貨幣及非貨幣(如積分等)數量變化的主體
存款賬戶、貸款賬戶、總賬賬戶、公積金賬戶
渠道ch
多個參與者為業務通訊的通道
櫃面渠道、atm渠道、**門戶
分類cl
資料分類或分組
前台類目、後台類目
業務方向
bd開展業務所在的環境或方式
-包含了500多個銀行的業務功能，不過沒有詳細列出。舉例如下：
方向管理
本處指工作流模型+流程模板。模板特點是：
作為模板化的分析和抽象，我們在設計中可以參考這些指導建議。
追求模型的大而全是不現實的，在特定業務主題下實際上只需要部分模型即可實現，以下是幾個例子。
建模後限於技術選型的限制，模型可能並不能直接套用。比如db不支援批量插入或效能很差、字段長度不支援等。這是乙個很常見的邏輯模型轉換物理模型時遇到的問題，對於物理模型的組織和儲存，需要進行進一步的設計，當然也有可能影響到邏輯模型。
對於領域模型非常複雜的場景，建模的最初目的是理解業務和溝通，可能並沒有考慮到系統間互動的複雜度。在將物理儲存轉換為邏輯模型時，組裝模型的介面可能會導致系統處理速度下降，特別是在大量資訊需要做序列化/反序列化時。在實踐中我們發現，對於外部只消費資料，不感知具體模型的結構，對吞吐量要求較高；對於內部資訊管理，才會感知到結構，但對吞吐量沒有太大要求。因此可以考慮將結構和資料分開儲存，對外介面只需要透出資料即可。
對於經常查詢的資訊預先考慮快取化處理。
模型支援可擴充套件，但不意味著把所有的處理工作留給自己，建議在保持核心邏輯和原子能力的前提下做擴充套件，保持內部的高內聚性，減少對外圍邏輯的耦合。下文會提到，「沒有一套模型能解決所有的問題」。
如果應用ifw的系統僅僅是乙個公司soa化架構中的一環，而非整個公司技術產品的共識，即使是乙個核心應用，上下游來對接會非常痛苦——他們不得不理解這套複雜的概念。這裡建議採用共建的形式為使用方提供sdk，遮蔽複雜的細節，僅僅提供給對方需要的資訊和介面即可。
與sdk化相反，如果僅僅關注系統內部流程，是沒必要完全實現大而全的ifw的，只需要實現其中使用到的領域即可。
「沒有一套模型能解決所有的問題，如果強行去做，那麼會導致每個模型都非常扭曲，這個是我們在經歷了這麼多迭代後得出的血的教訓。」這是我原先所在團隊的架構師在這套模型多年實踐後總結出的心得。
建設成本與使用成本的權衡。
ifw英文wiki：
zachman framework：
industry models產品官網：
架構設計最佳實踐之DRY
大多數的開發人員在講dry don t repeat yourself 的時候大多認為dry是功能和 的重複，也就是oaoo once and only once 其實不盡然。物件導向設計提倡的oaoo，強調的是利用物件導向的繼承 組合等特性盡量讓乙個功能點只存在乙個地方，所以oaoo強調的是物件導...
SOA架構實踐首先從企業級IT架構設計著手
各大軟體 商與 的聯合吵 作，使soa service oriented architecture 成為it人士經常掛在嘴邊的 時尚 詞彙。2006年，在日本舉行的年會上，gartner公司樂觀 到2007年，會有 超過50 的企業採用soa體系，到2010年該比例將會達到80 但事實上，到目前為止...
系統設計之架構設計
架構設計這個詞聽的非常的多，但真正何謂架構設計呢？可能要你真的來講還真的講不太清楚，很多人都知道架構設計是對系統進行分層 分模組進行設計，但又有多少人知道這步應該怎麼去做呢，往往很多的programmer在剛進入架構設計這個領域的時候，受到以前做模組的那種影響，把自己的眼光限定到了具體的模組實現上去...