這是 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：所繪圖刻意沒有加上表示關系的連線，側重于業務模型的物體物件的識別，
本文來源：http://www.cnblogs.com/x3d/，轉載請注明，轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/308437.html
標籤：面向對象
上一篇：類的關系（C++實作）
下一篇：分布式之配置中心