這個光頭有木有感覺很慈祥，他叫Martin Fowler，他是誰？爲什麼在一個程序員的博客中會有這麼一個人，就因爲他是光頭嗎？
可是如果說我告訴你他很少談論操作系統，數據庫，網絡這些底層的東西，也很少聽他談什麼高併發，海量用戶， 他也沒有開發過什麼知名軟件，但是卻被奉爲軟件開發的“教父”。你怎麼想！！！但是這確實一個事實
如果按照程序員的思維，把軟件分層
他其實生活在最上層：
這一層擠着很多程序員，因爲越往下層，路越難走。必須得能耐得住寂寞，經得起誘惑，對某個領域有着極爲精深的研究纔可以。
但是Martin Fowler在應用層卻能呼風喚雨，因爲他具備一個特殊的能力：擅長把一些軟件開發實踐總結成“概念”。
很明顯，這需要極強的抽象能力。
Martin Fowler 絕對是在應用層開發的程序員的榜樣！
爲什麼這麼說，因爲他對應用層開發的程序員太友好了，而大多數的程序員也是停留在應用層的，比如他現在正在合夥整理的模式的相關問題，開篇直接講了分佈式系統的幾個通用問題：
進程崩潰
網絡延遲
進程暫停
非同步的時鐘
進而引出分佈式系統的模式是如何解決這些問題的 。
比如非常經典的Write-Ahead Log 模式，可以用來解決進程崩潰時數據的持久化問題：
先把數據當作Command放入持久化的日誌文件中，這樣即使KVStore進程崩潰，在重啓以後依然可以從日誌中恢復數據。
大家很清楚程序員的交流語言是代碼， 所以馬上給出了簡單的代碼片段來幫助理解細節，真是很貼心。
classKVStore…
publicKVStore(Configconfig)
{
this.config = config;
this.wal = WriteAheadLog.openWAL(config);
this.applyLog();
}
publicvoidapplyLog(){
List walEntries = wal.readAll();
applyEntries(walEntries);
}
privatevoidapplyEntries(List<WALEntry> walEntries){
for(WALEntry walEntry : walEntries) {
Command command = deserialize(walEntry);
if(commandinstanceofSetValueCommand) {
SetValueCommand setValueCommand = (SetValueCommand)command;
kv.put(setValueCommand.key, setValueCommand.value);
}
}
}
publicvoidinitialiseFromSnapshot(SnapShot snapShot){
kv.putAll(snapShot.deserializeState());
}
但是今天什麼向大家介紹這個老頭呢？是因爲下載網上有很多分佈式理論的文章，乾巴巴的，看不了一頁就想放棄。網上也有很多源碼分析的文章，但是專注於貼代碼，糾纏於細節，讓人云裏霧裏。
Unmesh Joshi的分佈式系統模式則是個很好的平衡：既有理論，又有代碼細節。
1、如果你是一個剛入行的新手，看這些東西可能有些喫力，因爲需要有分佈式系統的基礎，不妨先收藏，等待以後再看。
2、如果是一個經驗豐富的老手，我強烈推薦你去看一看，觀摩下這些大牛們是怎麼從各種複雜的場景中抽取出通用的模式的，絕對受益非淺， 你可能有這樣的感覺：這種工作我怎麼就沒想到呢？
當然，這是英文的材料， 會有一定的障礙，不過你看了就知道，並沒有用什麼高級的詞彙，我列幾句大家感受感受：
Processes can crash at any time. Either due to hardware faults or software faults. There are numerous ways in which a process can crash.
It can be taken down for routine maintenance by system administrators.
It can be killed doing some file IO because the disk is full and the exception is not properly handled.
並不難，對吧？嘗試看一下吧，閱讀英文資料也是一項重要的技能。
最後爲大家介紹Martin Fowler最知名的幾本書
《領域特定語言》
說起DSL，我只着重強調兩點:
首先，提升開發人員的生產力;
其次，增進與領域專家之間的溝通。
如果DSL 選擇得當，就可以使一段複雜的代碼變得清晰易懂，在使用這段代碼時提高程序員的工作效率。同時，如果DSL選擇得當，就可以使一段普通的文字既可以當做可執行的軟件，又可以充當功能描述，讓領域專家能理解他們的想法是如何在系統中得到體現的，開發者和領域專家的溝通也會更加順暢。增進溝通比起工作效率提升困難了一些，但帶來的效果卻更爲顯著。因爲它可以幫助我們打通軟件開發中最狹窄的瓶頸——程序員和客戶之間的溝通。
《企業應用架構模式》
企業應用開發的實踐得益於多種新技術的出現，多層的面向對象平臺（如Java、.NET)已經日漸平常。這些新工具和新技術有能力構建更強大的企業應用程序，但是在實現上還不太容易。由於開發人員未能充分理解有經驗的對象程序開發人員在架構方面的經驗和教訓，因此企業應用中經常存在一些共同的錯誤。
《重構》
所謂重構（refactoring）是這樣一個過程:在不改變代碼外在行爲的前提下，對代碼做出修改，以改進程序的內部結構。重構是一種經千錘百煉形成的有條不紊的程序整理方法，可以最大限度地減少整理過程中引入錯誤的機率。本質上說，重構就是在代碼寫好之後改進它的設計。
《分析模式》
書中所提到的分析模式雖然包含了大量的領域知識，但適用於所有的業務軟件。像設計模式一 樣，這些分析模式很抽象，足以幫助你的軟件適應需求的變化;同時它們又非常具體化，很容易理解。它們不是最顯而易見的建模問題解決方案，然而我認爲它們是正確的。我以前曾經見過許多這樣的解決方案，它們都發揮了很好的作用
想要獲取這份資料的，關注+轉發後，去我公衆號：Java架構師聯盟，後臺回覆Java即可查看獲取方式