聚合架構：面向數字生態的構件化企業架構

純陽書評（豆瓣:純陽子/公衆號:純陽書評／微信號:chimbusco88）第465期《聚合架構》這本架構書籍，瀰漫着集大成的氣息。寫書的最高境界之一，就是寫到一個領域集大成的境界，而寫到這個境界至少需要三重功力，一是深刻把握該領域根本問題的功力，一個領域無論如何發展，如何演繹，其根本問題和本質邏輯往往是穩定不變的，所以抓住這條領域之魂是集大成者的根基。二是洞穿領域中各流各派優缺短長的功力，在一個領域中往往會出現多種流派、衆多體系，這些流派體系往往側重領域問題的某些方面，或者是在某些方面更爲突出，所以能夠基於領域問題洞悉這些流派體系的長短之處之集大成者的必要條件。三是兼容幷包、揚棄創新的功力，把握領域根本問題、洞察現有方法優缺短只是爲集大成找到了乾柴，基於問題、整合現有方法、推陳出新，把領域方法推進到高級階段纔是燃起集大成熊熊烈火的那粒耀眼火星。 第一、爲什麼說本書是一本瀰漫着集大成的氣息架構書籍。 如此評價的原因有兩個，一是作者顯然在企業架構領域展現出了上文中提到的三重功力。作者的企業架構系列書籍始終把技術和業務融合作爲核心主題，充分展現了其深刻把握該領域根本問題的功力。作者對Zachman、DoDAF、TOGAF、FEA等架構駕輕就熟的梳理和鞭辟入裏的分析，充分展現了其洞穿各流派方法論的功力。提出來的聚合架構吸收了Zachman的多視角架構、TOGAF的過程定義、DoDAF的原模型應用手法和DDD的業務與應用架構銜接方式，兼容各家之所長，體現了很強大的創新功力。 二是企業架構作爲一種方法論，最好的評價還應當是實踐和時間，邏輯上的評估再怎麼用力也會力所不逮，正因爲如此沒有直接稱這本書是集大成之作，而只是說本書瀰漫着集大成的氣息。所以說，儘管邏輯很看好，但是到底結果怎麼樣，還需時間和實踐來回答。 第二、這本書給有志於集大成者提供了一個努力樣本。 這一點絕對是本書的第二大看點。歷史上衆多集大成者往往只闡述自己的成果，很少向別人透露自己成功的路徑和邏輯，甚至還有不少像大數學家高斯那樣的人物做的更加過分，不但不肯透露而且還刻意隱瞞這一點，會像一個做了案的小偷一樣，花費一番功夫把可能透露自己祕密的所有痕跡，打掃的一乾二淨。 作者顯然大度的多，他在書中對自己的奮鬥歷程和努力路徑進行了無保留的分享。通過他的分享，我們既可以知道他是如何在企業架構領域中不斷進步，持續奔跑在通往企業架構集大成者的路上，也可以觸類旁通，感悟到一條在各種領域如何不斷精進並通向大成的路。其中一個祕密就是廣泛閱讀，大量閱讀，領域內的當然要讀，不讀領域之內不足以知領域之過往和潮流，領域外的也要讀，不讀領域之外不足以知社會之過往和潮流，而不知社會難以更好的知領域，顯然廣泛閱讀涉獵，絕對是集大成者的祕密之一。 最後，對IT人士強烈推薦本書，因爲本書即使尚不足以成爲企業架構領域的集大成之作，其作者也已奔跑在集大成的路上。

在找數字化轉型的書時無意間讀到此書。值得推薦與一讀 作者是有理論、實踐與教學的，這本書也是乾貨滿滿 作者也是借鑑了togaf的架構，但更注重戰略、組織與業務，這是很好的思路，因爲，畢竟建系統的目的就是爲戰略和業務服務，爲人服務，，但這裏的分析，我感覺組織適合放在業務之後，或者組織更多是約束條件，更影響權限管理。從某種意義上來說，做好了戰略和業務層架構，甚至是功能層架構後，再去匹配組織（組織是因變量） 作者使用的方法主要是還原論、mece以及域映射，在每個域中主要關注對象、關係與規則三元素。如此，以保證最終設計的目的性與合理性，結構的同構性與一致性 這本書還有一個附屬收穫，就是準備做企業能力建模，不同於EA，也不同與流程，，這個切入點貌似提的人很少，，實驗下，看能否成爲一個企業管理的新視角與抓手

企業級架構，結合國內金融業務實戰。 付曉巖兩本里這本更體系化，做企業級系統的人首選。

企業架構思維是數字化轉型的關鍵，企業架構框架是工具，可以評估一下聚合架構是不是最順手那個[得意]。 企業架構是一種強調全局結構化思維的設計方法論，ToGAF、中臺架構、聚合架構都屬於企業架構，它們都在試圖識別沉澱企業的核心能力，以更好地支持業務變化。

5.4　本書推薦的建模方法 傳統的建模方法一般會將流程建模與數據建模分開進行，但按照本書的觀點，這兩個建模過程應該結合在一起，從建模分析到建模結果，都應當具有直接的聯繫。軟件設計主要研究的是行爲和數據，業務架構之所以能夠成爲業務與技術的橋樑，不僅因爲其分析方法的結構化特徵，更在於它能夠闡明業務行爲與業務數據之間的關係，從而與軟件分析、應用設計之間建立連接。如1.4節中介紹的DDD模型一樣，傳統方法應當充分借鑑這種更有利於銜接業務與技術思維方式的表達方法。其實，從技術角度看待一個“構件”也是將行爲與數據結合分析的，比如面嚮對象語言中的類、DDD中的實體、微服務中的服務等。 本書建議將現有概念下的業務架構與數據架構合併爲新的“業務架構”，但是筆者也說過，這不是取消數據建模、數據模型的意思，而是將二者在建模過程中結合。 對於業務建模，筆者比較推薦BPMN方法，因爲BPMN表達能力豐富，總體而言面向業務但兼具業務和技術友好性，而且BPMN的建模方法也有比較成熟的資料，學習成本較低。當然，完整的業務建模還要結合戰略分析、價值鏈方法、用戶旅程等，本書會在後續設計指南中詳細介紹。 本書推薦繼續以ER圖表示法爲主建設數據模型，在工程實踐中注意加強概念級和邏輯級建模，但是目前的實踐經驗表明，在應用架構階段進行數據分析時降範操作是很正常的。降範並不代表無限開放，而是要保持對數據含義理解的一致，這是在企業級範圍實現有效的數據管理的基礎。金融領域可以參考IBM的方法論，對於其他領域，特別是沒有行業參考模型的領域，可以參照通用數據建模方法論。 相比於DDD，筆者建議繼續使用傳統的數據實體劃分方式，因爲流程模型與數據模型的配合也可以表達行爲與數據結合的設計，具有“直達”應用架構的效果。從傳統的數據實體切換到DDD的實體概念，例如聚合根、值對象等概念，可能會帶來額外的學習成本。雖然理論上二者可以形成近似於等價的設計結果，但相對而言，傳統的數據實體分析方法更利於企業級的數據管理。 筆者在此再次強調，不深入結合業務，忽視概念級、邏輯級數據模型的價值而直接進行近似於物理級的數據設計，可能是當前數據建模領域存在的主要問題，這並不需要通過“改換門庭”來解決。 ​ ​另外，筆者還想談談實際操作建議。 業務建模和數據建模不應分別進行，而應該同步開展，二者在模型表達上也應該結合緊密，以BPMN語法中的任務爲基礎，將任務中關聯的數據實體在任務的描述中表達出來，並根據任務與數據的關係考慮任務邊界的切分，按照“高內聚、低耦合”的原則形成邊界重疊儘可能少的“構件”。 這一過程可能需要經歷一定的反覆甚至重構才能達到較爲理想的程度，但這並不妨礙架構設計的正向開展，畢竟，任何一種架構方法設計出來的架構成果都是需要打磨的。 筆者提出的流程模型與數據模型的配合也不意味着要在建模方法上做很大的變更，方法論的發展未必是對方法論的徹底改變，更重要的是視角的調整，將可能導致分離的視角緊密結合，將不需要糾纏的視角分開。而當前我們對於數字化的關注，以及對於業務架構與應用架構銜接的關注，其實是要求我們嘗試將業務架構和數據架構分離的視角整合。“一切業務數據化，一切數據業務化”，這個口號很好，但是要如何落實？筆者提出的建模思路就是一種可供參考的方法。

聚合構架按邏輯思維次序化組成體系結構設計過程。企業建立信息化規劃，對信息系統建立清晰、可操作的流程、權限和職責體系，並對信息系統進行持續評估優化。

更適合諮詢公司的朋友閱讀，理論、總結太多，實踐太少。

宏觀，泛化，有些內容不太能想象到。作者畫的圖很不錯👍

2024 第一本囫圇吞棗讀完🥴，估計也是半年來第一本，繳費後有待提高(｡_｡)📖謝謝

假大空的感覺，純理論性總結，絲毫沒有介紹應用案例。