对架构设计的一点看法

在软件开发领域，架构设计无疑是非常重要的内容。中培教育《软件系统详细设计最佳实践》培训专家龚老师指出，架构应该包括了功能性架构和非功能性架构两个方面的内容。我们常说的J2EE，DotNet标准架构框架更多的是非功能性架构的范畴；而谈的子系统，组件划分，接口设计，复用等内容涉及到功能性架构的内容。J2EE架构的标准模板很容易找到和借用，但是并不代表你是一个合格的架构师，架构师必须深入到功能性架构中，真正的做好需求和实现中间的桥梁。

龚老师认为，从静态分析的角度来考虑，架构的核心即是分解和集成。我们面对的现实业务和需求可能太庞大了，如果不去分解我们的构建根本都无法下手，我们就无法真正理解业务细节。因此子系统和组件划分是分解重要内容，分解重要原则又是高内聚，松耦合。

由于分解产生了组件间的交互，因此需要根据关注接口的分析和设计，架构师的一个关键职能就是要屏蔽系统本身复杂性，将复杂性作为一个黑盒控制在自己手里，对外只需要暴露尽可能简单的接口。而在分解的时候又必须要考虑集成，架构师在自己脑海里面已经有了目标系统的样子，他们会很有信心分解的组件能够通过当初定义的接口很好的集成在一起。正如汽车制造一样，所有的零备件都出来了却发现它们根本无法组装成一台汽车，这对架构师是最大的悲哀。系统都还没有出来，而架构师就能够游刃有余的做这些事情，靠的不仅仅是多年的设计和开发实践，更多的则是在实践过程中的抽象思维和模式总结。

从动态分析的角度来考虑，现实世界中的原始需求进入，最终出来的则是满足需求的功能实现，在这个过程中涉及到一系列的内部程序流转流程，前台界面，业务逻辑，数据访问，数据实体，公用组件等，这些层次之间应该怎样去交互是在架构设计中必须要考虑清楚的问题。在这方面我喜欢用架构机制这个词语，机制往往并不是静态词汇，因为要深究机制就必须要搞清楚事件触发，功能调用，访问顺序等一系列问题。简单的讲，架构机制要回答一个重要的问题，即你设计出的分布式框架如何能够满足输入的需求变成最终输出的功能，中间究竟经历了哪些步骤？安全性如何保证？性能如何保证？可扩展性又如何保证？要回答这些问题你都必须给出这些问题的解决方案的运行机制，而只有大家认可了运行机制，或者新出来的模块已经在新架构上运行验证了，才能够讲从架构框架上基本上已经成熟了。

架构本身不是目标，而简单实用并且支持灵活扩展的系统才是我们追求的目标。架构师思维意识里面更加重要的是实用性和经济性而非理想化，由于业务域和问题域的不同没有完全可以照搬的架构，在架构设计上追求一定的可扩展性，要杜绝过度架构和架构理想化的问题。就如何建造一个建筑，如果我们最终得不到一个实用的的建筑物，你再怎么向客户吹嘘你的设计图纸和建造框架如何合理都是徒劳的。