今天面试一个牛人，跟我们谈起了他做过从UML到生成代码的工作，而这正是俺发展的目标－架构设计。所以当时我就问了下他跟架构设计密切相关的设计模式的一个－桥接模式，他没接触过。

         晚上回来，我本来想把个系统源码再研究下，好方便下一步的工作，但总觉得自己少做了些什么。

         架构设计决定着软件产品。

         这是我以前经常听到的一句话，但现在的项目，对于我来说，就是把一些比较出名稳定的开源架构拼接起来，比如SSH(spring+struts+hibernate)，很惭愧，这就是我的架构。

          大家都说开始的架构是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持。再结合自己项目的特点(需要透彻的系统分析)，然后逐步形成自己项目的架构。

          然而，做项目的我们，都深有体会，总是抱怨客户的需求老是在改变。往往问题本身并不是很困难，但是代码维护性的要求总是很高 ，但往往我们做到后期就很难去重新架构自己的项目（导制这方面的因素很多）、丰富完善了设计方案。

        工程项目方法（RUP或XP ）为我们提供了架构设计的正确完成保证。

         运用成熟的模式设计进行架构设计成为了必然，设计模式成为支撑架构的一种重要组件，但如果为了模式而架构又会成为你项目的绊脚石，所以，如何正确的应用又成为了一个很重要的课题，但这些前提都是以熟悉各种设计模式为前提的，这其中最重要的一点就是：时刻牢记架构设计的目标。

         把握目标的点，我从网上扣了过来（哈哈～～～，有网络就是好）

         1. 最大化的重用：
         这个重用包括组件重用和设计模式使用等多个方面。
         比如，我们项目中有用户注册和用户权限系统验证，这其实是个通用课题，每个项目只是有其内容和一些细微的差别，如果我们之前有这方面成功研发经验，可以直接重用，如果没有，那么我们就要进行这个子项目的研发，在研发过程中，不能仅仅看到这个项目的需求，也要以架构的概念去完成，这个可以称为组件的子项目。

         2. 尽可能的简单明了
         我们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。但是在具体实施设计过程中，我们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，因此如何尽可能的做到设计的简单明了是不容易的。

        落实到每个类的具体实现上要真正能体现系统事物的本质特征，因为事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了，越简单明了，你的系统就越可靠。更多情况是，一个类并不能反应事物本质，需要多个类的组合协调，那么能够正确使用合适的设计模式就称为重中之重。

        我们看一个具备好的架构设计的系统代码时，基本看到的都是设计模式，宠物店(pet store)就是这样的例子。或者可以这样说，一个好的架构设计基本是由简单明了的多个设计模式相互配合完成的。

        3. 最灵活的拓展性
        架构设计要具备灵活性 拓展性，这样，用户可以在你的架构上进行二次开发或更加具体的开发。而要具备灵活的拓展性，就要站在理论的高度去进行架构设计。

        比如现在工作流概念逐步流行，因为我们具体很多实践项目中都有工作流的影子，工作流中有一个树形结构权限设定的概念就对很多领域比较通用。树形结构是组织信息的基本形式，我们现在看到的网站或者ERP前台都是以树形菜单来组织功能的，那么我们在进行架构设计时，就可以将树形结构和功能分开设计，他们之间联系可以通过树形结构的节点link在一起，就象我们可以在圣诞树的树枝上挂各种小礼品一样，这些小礼品就是我们要实现的各种功能。有了这个概念，通常比较难实现的用户级别权限控制也有了思路，将具体用户或组也是和树形结构的节点link在一起，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具备很灵活的拓展性。