什么才是软件架构呢？这是一个让人费神的事情，其实呢我觉得“软件架构”至少应该是一个动词，而不是一个专有名词。那么什么才是架构呢？按照我个人的理解，架构这玩意简约不简单。“架构”的过程是一个把抽象转化为具体，其中的美妙不会低于设计师创造艾菲尔铁塔那般的感受。架构的过程会让你变得偏执、疯狂。至少在短时期内会为之寝食难安。那时时候你的世界之后架构二字了。有点长，希望耐心看完～～～ 哈哈！
（PS：尽管架构是与编程语言无关的事情，目前采用Java语言作为例子）
好了，很多人读到这里会怀疑，难道J2EE业界流行的那些SSH、SSI 不是架构吗？我的回答是“NO”，如果硬要如架构沾边的话，那也充其量是一个架构最最低级的一种。在现在的我看来，那些只不过是一些开源框架的简单集成，毫无技术含量可言，对于架构者本人而言，那就是通过固化的配置把这些开源框架进行一定程度的粘合，使其能互相配合完成工作。当然不是否认这个配置的过程，但是这个过程是机械化的学习，丝毫看不到自己的想法，这时的想法都被固化的配置所代替。想当年 偶也是这样子走过来的，所以说呢，现在的我不敢谈论架构的内涵，仅仅是表达出我对架构的一些想法。文以记之。
好了，经过SSH简单的粘合之后，感觉自己很伟大，而且看是跃跃欲试的样子，拿来做项目，这是必经的一部，从程序员到架构是一个设想与实践相结合的一个过程。你自己架构的东西必须通过项目的实践，才能了解是否有改进的余地。我是比较幸运的，一直以来很多项目都是我架构之后在实践呢，在这里感谢那些曾经呆过的公司。是他们给的平台才让我有今天坐在这里写文章的冲动。很多人在使用简单粘合的SSH框架去架构你的项目，你会发现那玩意不适合做项目，太原始了，仿佛回到了石器时代，当然当时你的水平估计也就是才进化到铁器时代吧。
第二阶段了，开始尝试修改SSH搭建的框架，新在而言还是用“框架”来形容比较的贴切一点。通过一轮或者几轮的项目实施，你会发现其实SSH等这些也不是很完美，至少还有很多地方可以改进，这时你已经不再满足于SSH的简单那粘合了，开始尝试去修改加工SSH的粘合。增加一些与SSH直接交互的隔离层代码，这样一来自己项目的代码干净了很多，SSH从入侵式到非入侵式（不可能100%），这已经是一个了不起的飞跃了。你发挥了作为人主观能动性的权利，现在你收获了。那改造的SSH继续项目到项目中去实践，也许改造后的架构在当时的你看来已经很完美了。勇者无惧，Going，开始第二阶段的试水，感觉很好吧，现在的你也许长大一点了，不再从单一的技术去看待项目了，开始考虑项目的开发计划了，有了后则一层的考虑说明你是一位勤奋好学的好孩子，已经不再是单纯的Coder了，面对计划，在看看自己的架构的“框架”，时间紧迫啊。用这玩意尽管目前代码尤雅了很多，但是对于项目小组成员的开发进度还是帮助不大，大家需要学习的东西太多了，Spring、Struts、Hibernate ....... 这对于经验不是很丰富的程序员而言，简直就是噩梦。考虑到这一点，你就开始进入第三阶段的进化了
第三阶段，开始思考屏蔽各种框架集成带来的复杂性，让不懂SSH框架的人也可以快速上手使用，为了达到这一点，又开始废寝忘食的框架重构，增加更多隔离层的代码。这时的框架有点架构的味道了，重构之后的你会洋洋得意，认为这是很完美的了，又去屁颠的拿去项目实战了，这时发现你隔离之后的反而适得其反，百思不得其解啊？什么情况呢？因为你对粘合的框架内核机制不了解，这时的你要虚心学习那些开源框架了，必须是源码级别的阅读，了解他们的内核机制，才能写出更好的隔离层，面对大量的源码，必须有个入口吧，下面我简单吧Spring的入口告诉大家：首先是Spring的Ioc容器，这是核心，主要是看init bean以及loadbean的这点内容是精髓，Aop的话比较深入了，简单一点就是采用动态代理方式实现AOP，在高级的就是采用CgLib的动态代码切入实现。学好这两个之后。在学习Spring MVC 了，这是一个难点，你要吧Mvc的解析流程整理好了，在从每一个环节思考架构为和要多一个这样的环节。（Struts1 太简单了，Struts2太复杂了）。言归正传了，经历一轮源码的洗礼，你脱胎换骨了，SSH对你而言 使用起来游刃有余了。你再也不用为框架不熟悉费力了，这是的你充满了自信，短期内不再关注学习框架了，更多的时间分配给了架构。这时应该进入第四阶段了吧
第四阶段，开始用全新的眼光以及思维去粘合SSH，不错，很多以前的使用不当现在都让你轻易的化解，而且开始考虑使用SSH特有的一些优势去美化的你的架构。现在的你开始考虑的不是开始了，而是如何保证代码的质量问题了，如何保证呢？好吧，找领导申请资源测试吧，对不起，测试团队是很昂贵的，公司很少会配备测试团队的，自测？小弟们才不会如此上心呢？未雨绸缪吧。架构时候为何不架构一套基于SSH的单元测试框架进来呢，好处呢可以脱离容器去测试功能，基于框架的单元测试进入了你的思考范围。等从思考到完全融入架构的时候，你有进入一个新的阶段了。编写测试架构就是为了提高工作效率，目前面向Web的开发，很多测试都需要依赖容器，每次启动容器调试是何等的低效啊。好了集成了自己的测试框架，小弟们高兴了。也会对你刮目相看，至少编写单元测试是一个程序员的义务，保证自己的代码的稳定性，现在你轻松了，每天吧小弟的成果用写的单元测试运行一次。没问题了，不错。下班。
第五阶段，也许这一阶段你的架构开始稳定，很长一段时间都会固化不变，也许到达了一个瓶颈了。单位来了狠多项目，每次你都构建一个基础成，1次 2次 。。。N次，O-MyGod，你开始讨厌这种重复的的劳作了，得，这是你的责任，你是公司的技术一把手，这些肯定有你来做。这是你开始考虑吧基础层与业务层开始解耦。解耦出来的东东作为单独的一个项目存放，自己手动维护，以及版本控制。新建的项目都依赖你的基础项目在做业务开发，现在感觉好多了，不用在为项目每次都搭建了。看着别人在忙，你在一边抽烟偷着乐吧。新在的你体会到一丝分离的快感。这不是就是所谓的程序的解耦吗？这不过你解耦的比较彻底了，从功能和物理上都实现了解耦。恩体会到设计模式的优美了，这是你也会才会发自内心的去迷恋设计模式。这些设计模式是前辈们精华的抽象，不同的模式用于解决各种现实的业务建模。学会是一回事，灵活掌握是另外一回事。关于设计模式，是必经的过程。不仅仅是学会，关键是灵活使用。在合适的场景下选用合适的模式，才是正解。
第六阶段了，通过之前的积累，你已经开始迈出走向架构的第一步了，之前都是为这一步的积累。好比是砍柴，之前都是磨刀了，现在才开始踏上砍柴的路途，哼着儿歌、一路进发。现在刀不是问题了，估计之前的砍柴都是刀不好，注意力都在刀上了，现在刀是没问题了，开始转移到观察柴了，什么柴比较好，砍哪里可以一刀成功，这些多是经验。映射到软件项目就是，开始关于业务建模，不同行业的业务都有其自身的特性，如何针对这些特有的业务特性去架构框架呢，在之前的隔离层上在封装一层业务支撑体系，这个体系可以良好的为业务系统提供强大的动力。通信、政府、金融、医疗、企业、税务、电商。。。。等等，每种行业有有其自身的业务特色，干活去吧，都发现架构的不足了，那就继续完善吧。coding～～～～～好了，针对业务的支撑层也开发完毕了。通过实践运行不错。。。。。 这时你的框架成了公司的某一业务线的开发平台了 。。。。如果继续留在公司，你也许会不断完善其业务建模的支撑体系。可惜，你可能换工作，换工作就意味这换行业。之前积累的业务体系完全行不通啊～～～悲剧了，没办法，从小弟开始做起吧，虚心学习业务基础 。。。。
第七阶段，跳槽太多也不是坏事，经历了几个不同的业务线，你敏锐的嗅觉开始体验到一些独立与业务之外的程序处理规则。如何能搭建一套快速满足不同业务建模的基础模型出来，说到底业务到了底层还是各种流程，只是每个流程节点处理的内容不同（不是工作流，但有其思想）。这时候，你考虑的问题已经不是业务建模了，而是业务之外的东东，这个时候你会忘记SSH这些所谓的框架，这些都是具体的形式体现，现在你需要的是高度的抽象，抽象业务之外，流程图是你研究的核心，因为任何程序其实都可以用流程图去表述，如何开发一套流程配置解析引擎呢，神码业务都是流程上的一个节点而已。只要业务流程化，按照我的配置写入，那么他就可以运行。见山不是山的境界吧哈哈～～～ 到了这一步了，感觉架构才是正的开始了。当然框架是抛不开的，现在面临的问题就是如何利用既有成熟的框架是完成你的这些构想，现在的框架开始考虑自己的分层了，内核层、安全层、缓冲层、ORM层、异常处理机制、国际化机制等等，是不是一项伟大的工程呢，也许Spring就是这样子走过来的。完成了这一阶段的修炼。那么你还不满足吗？恩的确有点就是说不出来，总是有点不满足。现在开始讨论更深层次的话题
第八阶段，架构是有了，你的项目规模也越来越大了，用这个玩意的人也越来越多了，现在考虑的是如何把你的框架能快速推广，市场是检验产品最好的标尺。是否具有可用性。是否能量产程序员（入门级），是否能保证代码的质量、是否能保证出现问题的快速定位，是否能够满足业务扩张的需求、是否满足性能的要求………………….. 咳咳～～一口气说完 太累了！！这些问题是现在需要考虑的问题了。现在架构的推广不仅仅是你的团队在用，也许其他团队也在用，可惜他们无法得到你的亲授，肿么办?开始文档化、标准化、提供实例Demo，这些够了吗？对了 还不够，100个程序员有100中独立风格的编程方式，那就意味这有100个风险的存在，你的架构如何屏蔽或者降低这些风险呢？答案呢？就是要用你的架构去诱导他们尽量编码风格一致。其好处不言而喻啊，统一的编码风格意味这每个程序员都是平等的，从项目角度考虑，那就是把人的风险降低了（包括离职风险）。带来的另外一个好处就是Review代码的快捷，统一风格的编码无需讲解 ……. 自己体会吧。说再多也是没用这个要亲自体会的。到了这一阶段感觉自己是什么？在雕琢一个艺术品？哈哈～～ 这个时候更加需要实践，去完善你的架构。因为现在你的架构是真正的架构吧。这个需要天时地利人和多方面的支撑。能达到这一步的程序员需要的不仅仅是自己的努力了，也需要公司的大环境……………….. 这就是为何什么程序员需要找适合自己发挥的平台。公司成了员工技术发展的桎梏。其结果就是让其平庸，或者释放去更宽广的空间。哇塞。好长久的文章啊。读者看到这里，需要休息休息了，找几张美女图片看看吧～～～也许我的文章让你费力了。现在OK了吗？架构可以了吧。恩 还是有差距的。
第九阶段，见山是山，再次回归项目中来，项目的目的是什么，盈利。这是最本质的东西。偏执也好、狂热也罢。这是一条基准，违背这一原则的任何架构都是失败的架构。盈利不是结果，而是项目每一步风险规避的积累。架构这是需要考虑的就是如何让架构能在每一阶段都能起到规避风险的功能呢？这是一个比较空洞的概念。但是这是必须考虑的，涉及到架构任何一个细微之处的调整。从项目开始到投产到维护。。。。这个过程，架构如何能保证每一阶段的风险规避呢。或者提供解决风险的更好的方法 ………………………..
上述为架构师修炼的过程，架构是具有中国特色的架构。不同于国外，一些老外闲的蛋疼去研究，我们都是苦逼的项目中提炼自己，利用8小时睡觉，8小时工作之外的时间去完成这一修炼，上面的文字也是本人的程序开发的成长历史，抛砖引玉吧～～希望能对开始“架构”你提供一些参考。最后浓缩几个字，算是文章的目的！
盈利、重构、坚持 。