系统架构设计原则及其他

  系统架构是一个极具弹性的概念，每次看到architecture这个词，我都不由地感觉自己身处一片空地，而自己要在呼吸了一大口西湖清晨的空气后，于日落前在此建造一幢住宅。对于盖房子而言，这也许是mission impossible，但对于软件系统架构设计，未必不可行。

  但如何进行架构设计？是否有可借鉴的设计原则和方法呢？Mark Schultz在2007年3月发表《Architecture principles: Creating the foundation for robust architecture》一文，从通用架构、业务逻辑、技术、信息与数据、管理、发展趋势、安全性、测试等8方面探讨了在进行系统架构设计时需要考虑的问题，除了一些软件工程中经常提到的保持易用性、可扩展性、安全性、可测试性等一般原则之外，他对某些问题的强调值得系统架构设计人员深思。

1.在通用架构方面
**充分重视非功能性需求
非功能性需求应该与功能性需求一样进行认真地设计、开发、测试和管理。
**单一视图
无论在何处访问，以IT系统架构为基础的应用应该能够提供一个与业务流程集成的一致视图。
**不要试图自己开发所有东西
除非是极有必要，不要自行开发业务应用软件、系统组件、或功能框架，通常购买成熟产品或者选择声誉良好的开源产品是更好的选择，Struts、Spring、Hibernate、Linux已经证明了Open source项目也是值得信赖的。

2.在业务逻辑方面
**技术风险
在一个业务系统的生命周期内，其稳定性很大程度上取决是所采用的技术是否是可控、可管理的。开发人员总是喜欢尝试新技术的，但新技术能否融合入这个业务系统之中，则需要认真评估。

3.在发展趋势方面
**开放标准
尽可能采用业界成熟的开放标准，在自己试图定义某些协议之前，最好现考察一下是否有现成的协议可用。以前在开发一些智能控制产品时，我们采用了RS485串行总线，但由于RS485是底层协议，于是我们自己定义了一套上层通信协议，而事实证明这种做法很值得商榷。

4.在安全性方面
**受控的风险
根据业务目标，风险与安全性之间应该达到一种平衡：不为无谓的风险强化安全性，也不为实在的风险弱化安全性。系统安全程度与系统构建维护成本总是成正比，在系统设计时就需要考虑如何达到一种适度的安全。

在技术世界有太多原则，例如关于OO设计，有一篇有意思的文章（http://blog.csdn.net/jesyy/archive/2009/03/03/3953965.aspx），归纳了61条设计原则，虽然琐碎，但似乎都是有价值的。系统架构师其实容易受到类似文章的引导，一条一条地与自己的工作进行比对。设计模式则是另外一个典型的例子，如果设计没有某个pattern做倚靠或铺垫，系统设计者便底气不足。我想，在实际需求面前，所有技术原则都是可以打折扣的。如果一个应用只有若干简单的Request-Response，是否非要套用MVC模式呢？未必。把问题变得复杂化，除了可能展示设计者的博学之外，只能增加客户的负担。

简洁，最美也最有效。