MartinFowler用最通俗的语言阐述了软件架构的本质“软件架构就是那些一旦确定了，就很难更改的东西，所以确定之前一定要谨慎再谨慎”。
如何才能合理的设计软件架构呢？
林巴斯，克莱门斯等在书中定义了架构设计的方法学，我总结如下：
第一步：收集需求，万事起于需求，没有需求什么也定不了。
第二步：从需求中识别架构驱动因素。比如“我需要一个注册登录页面”这样的需求不会驱动架构的设计，而“我们有500万用户”会驱动架构设计。
第三步：根据架构驱动因素制定出“架构风格”，也是最困难的一步。架构风格优先于架构，是架构的指导方针。按照罗伊博士的话说架构风格就是作用于架构之前的一组约束。这时候肯定会出现很多相冲突的因素无法全部保全，比如“并发量”和“吞吐量”是天生的冤家，这时候就要反复结合需求看看这个软件到底核心价值在哪里以决定优先保全谁。著名的架构风格有：“管道过滤器”，“分层”，“黑板”等等。
第四部：根据架构风格设计架构，保证架构没有脱离约束的控制，这样的架构才是可信服的。对于JavaEE应用来说，由于不像C#一样是full stack的，往往不会自己从头设计架构，更多是选择架构组合，这经常比从头设计更困难，因为你要知道所有的才能对比，看看哪一个最大程度地满足已定义的约束，这也是JavaEE好的设计难以做出来的原因。
但是现在的很多国内项目，往往不是按这个步骤设计，分析原因如下：
1、教育问题，架构师无法满足以上的技能要求，甚至在需求之前就确定了SSH架构
2、产业问题，很多厂商为了在项目中卖自己的平台产品，强制要求项目开发商必须用其平台API开发，无论需求是什么
这使得广大国企开发人员置身于水深火热来解决平台无法支持的问题，陷入焦头烂额的状态。
