这个光头有木有感觉很慈祥，他叫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即可查看获取方式
网友评论