這是 Martin Fowler 在《企業應用架構模式》之前出的一本二十多年前的書，中譯本是2020年4月纔出版，由與 Martin Fowler 在同一家公司 ThoughtWorks 的鐘敬翻譯。我在團隊內部向小夥伴們介紹架構方面知識時，提起ThoughtWorks 這家公司，一直將其評價爲軟件界的聖殿。
信息系統的架構，拋開單機模式不談，從C/S模式到B/S模式的架構遷移，大致就是這二三十年間軟件開發領域發展軌跡的一個總體輪廓。在這背後驅動的，很可能離不開以 Martin Fowler 《企業應用架構模式》爲代表提煉出來的三層架構和 MVC模式等。
（我畫的一個整合模型圖）
而相對於ThoughtWorks這些專業軟件企業，另外那些互聯網大廠，因爲應用的體量巨大，解決這類問題的動機導致他們給軟件行業最大的貢獻，可能僅在於擴展了這些架構模型中的層級，在軟件工程層面貢獻甚少。以雲計算中涉及的存儲爲例，見下圖：
（來源網絡，找的這個圖可能不太精準，主要是表達這種層次化架構視圖，不斷出現的新的中間件，就是這種層次化層級增加的表現）
所以我們的互聯網公司的軟件工程師們，因爲這些層級的不斷加深，被迫要更不斷的新手上掌握的工具，以保持與行業的同步。可是，從軟件工程過程的視角，這些工具主要是”實現“階段的事務，也就意味着逐步的軟件工程過程的其它階段如需求分析、設計，已經快要無力深入，終於只能託付給其他專人，於是造成進一步分工（某種說法叫”殘化“），淪落（某種程度上的現實）爲”碼農“。
（國標中定義的軟件生命週期八個階段示意圖）
《分析模式》這本書重點探討了在軟件開發活動中，從軟件工程過程視角，”分析“階段的模式總結，及將模式模型從”分析“階段到”設計“階段轉換的方法論。所以這本書主要面向分析、設計、實現三個階段中處於分析階段的分析師。這類書籍，要求讀者擁有一定的抽象思維能力，有那種“形而上”的邏輯學或哲學意味，所以如果感覺讀不下去的時候，可以停下來，從頭開始讀，給腦子更多聯想和想象的提取機會，必能有所助益。開卷有益，開一遍不行，就開第二遍，第三遍。
當然，我個人觀念中理想的軟件工程師是對應於三個階段所謂分析師、設計師、碼農的結合體，是爲”全棧工程師“。《分析模式》中講到分析模型與概念模型、領域模型指代的是同一種內涵。以個人膚淺的理解，DDD領域驅動的開發，某種程度上就是這種”全棧“導向的一種趨勢和方案，那我們就要從學會分析系列現象問題所湧現出來的模式（Pattern，用另一種譯法”斑圖“理解起來更爲直觀）開始。
書中的給出的第一大模式是責任模式（accountability），這是所有涉及到業務關係梳理時，繞不過去的第一道坎。這個模式是從組織建模問題引申的出來。當我們做企業應用系統分析時，首先要就梳理企業的組織架構，我們在職場所常見的那種組織架構圖，往往也是五花八門的，而站在”稍高一點“視角（《用系統工作》）的模式定義，要兼顧當下的易用性與未來的靈活性，最低標準是識別出組織層級化模式，更高標準是識別出分離組織、組織結構、組織結構類型的模式，再高標準，就是更抽象通用的責任系列模式。
簡單舉例來說，一家全國性集團企業，一般有總部、各”子公司/經營單位（operating unit）”、往下按“業務分片/地區（region）”、再往下”分公司/分部（division）“、最後“網點/辦事處（branch/office）”，如果在見到如此確定的組織業務結構的時候，我們第一反應一定是分別建立這四個模型，因爲這太明顯了。
（獨立的四個模型）
可是，分析模式要求我們站在比當前所在“稍高一點”的視角，感受和分析那種可能性變化“湧現”後的情形，進行分析和識別。然後就會發現這種由四個獨立模型在業務結構變化時比如去掉“地區”，就需要整體改變模型之間的關係，進而要求我們不得不提取出一種更靈活一點的模型如組織層級模型，將組織和組織結構合併爲一個模型，通過層級屬性來表達組織結構的約束關係。
（組織內部的層級關係通過一個層級屬性來表示）
如果再往下分析更多可能性湧現，就會發現這種組織層級模型，主要是假定組織只存在一種結構關係，當要定義多種結構關係時，便不夠靈活，於是不得不將組織結構關係/類型從組織的屬性中獨立出來，以便支持多對多的場景。
(將組織和關係分離後，組織結構爲組織與組織結構類型之間的關係)
這時，我們發現我們分析的對象就變成了“組織”和組織之間的結構關係/類型，“組織結構”是關係的產物，關係背後的約束規則以及隨着規則變化形成的歷史記錄，可以進一步再建模。
（組織結構成爲了一種業務流程數據，需要記錄業務流程軌跡，而非僅是我們常規理解的基礎數據）
進而，一旦涉及到業務流程，從“稍高一點”的視角，業務的各參與方就存在“責任”，責任可能會發生變更，同時在兌現“責任”的過程中還產生了相應的活動。
（責任模式下的實體模型）
進而，通過資深領域專家的分析，不斷的識別湧現出來的模式，用一種模式解決對應的一系列所有同樣問題，後續在軟件工程過程中以這些模式爲溝通語言，形成的是一種普通分析師“套用”這些模式的局面，就不再需要經歷重複的從頭的多次迭代才能解決一類問題的尷尬。當然，別忘記我們的總體目標，學會平衡易用性與靈活性，用句行業黑話來說，就是“軟件的實現來源於客戶的需求，高於需求，最後滿足需求。”
PS：所繪圖刻意沒有加上表示關係的連線，側重於業務模型的實體對象的識別。