软件架构设计的常见误区及解决办法 

    1、架构设计的常常会“高来高去”。所谓高来高去，实际上就是我们的架构设计仅停留在模型阶段，但也绝不是产生第一支样例程式。

    2、架构设计时常常会在某些方面过度设计（Over engineering）。为了一些根本不会发生的变化而进行一系列复杂的设计，这样的设计就叫过度设计，往往会带来资源的浪费并且会增加开发的工作量或难度。虽然我们必须考虑到系统的扩展性，可维护性等，但切忌过度设计。有时候或许你并不能判断出哪些设计是过度设计，此时你可以请教你的PM，让他站在整个项目的高度来帮你决策一下。

    3、架构（Architecture）不是框架(Framework)，也不是简单的将几种框架或技术的组合，框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，我们可以用一句较为经典的话来总结：框架是软件，架构不是软件，框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架。

    4、架构设计绝不是新技术展示平台，合适的技术才是对于项目有利的技术，必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节。

    5、架构设计的成功与否决定着系统品质的好坏，因为架构设计不好而导致交付的系统Bug过多，无法满足客户非功能性需求等问题，从而导致项目取消的案例时有发生。架构设计不是架构设计师一个人的事情，也不是几天就能完成的一项工作，必须是架构设计师付出大量辛勤劳动后的成果，其成败往往与组织、主管、项目经理的支持有着密切的关系。

    关于架构设计的一点通用技巧

    1、分层（Layer）规则。这里的层是指逻辑上的层次（Layer），并非指物理上的层次（Tier）。目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层。在对各层次进行划分时，主要可以从以下几个方面来考虑：A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；B、将层次间的依赖性降到最低，即降低耦合；C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；D，层次并不能封闭所有的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段。同时，过多的分层可能会对性能造成一定的影响。

    2、包（package）之间不要产生循环依赖。通常包的划分会先按不同的逻辑层来划分，在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则，这样的规则一定有其存在的价值和道理，之所以这样主要是出于以下原因：A、循环依赖会使分层失去意义；B、循环依赖会带来许多潜在的风险，如可能会产生嵌套事务（nested transaction，JavaEE标准中并不支持这种事务）的现象，我就曾遇到过这样的问题，在一个项目中，事务放在业务逻辑层统一控制，但由于开发人员忽视了架构中这样的原则，在持久层调用了展现层的公用类，形成了回圈的现象，导致了嵌套事务的发生。

    3、设计模式的应用。在很多人的观念里，提供设计模式就等同于GOF的设计模式，其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具，是人们对于过去解决某一类问题的经验总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前一定要先分析清楚问题，否则就可能出现“牛头不对马嘴”的现象。

    成功的项目总有相似之处，失败的项目却各有各的失败之处。好的软件架构设计必定是成功项目的相似之处，我们有什么理由不把软件架构设计做好了？