1、基本原则 在开始设计以前，考虑主要的设计原则将有助于找到架构的设计的“最佳方案”，下降成本和维护须要，提升系统的可用性和可扩展性。主要的设计原则以下： 关键点的分离：将应用程序分红清楚的不一样元素，使功能的重叠尽量的少。 单一责任原则：每个组件或模块应该只负责惟一一个特定的功能。 最少知识原则：一个组件或对象应该不用知道其余组件的内部实现细节，而只要按照彼此的约定调用便可。 不要重复本身：一个组件对应提供一个功能，一个功能也只应由一个组件提供。而不能将功能的实现分散到不少其余的组件中去。 避免在前期作大量的设计：若是你的需求不是很清楚，或者有设计随时间演变的可能，应当避免在项目前期作大量的设计工做。这一设计原则一般被叫作“BDUF”。 多用组合少用继承：在尽量的状况下，使用组合的方式来重用功能，而不使用继承的方式。由于继承增长了父子类之间的依赖关系，限制了子类的重用。 2、设计要点 在设计软件或系统时，软件架构的目标就是经过将设计分割为不一样的关注领域来下降其复杂性。例如，用户接口、业务进程和数据访问都可视为不一样的关注领域。在每一个领域内部，组件应专一于其特定的领域，而不该该混合其余领域的代码。例如，UI进程组件不该该包括直接访问数据源的代码，而应该使用其余的业务组件或数据访问组件检索数据。 下面列出了设置应用程序的指导方针： 避免在前期作全部的设计：若是系统需求不清楚或存在设计演变的可能，在前期不去作一个完整的设计应该是一个好主意。在项目进程中演化设计应该是一个恰当的方法。 分割关注领域：将应用程序分红清楚的不一样元素，使功能的重叠尽量的少。这种方法的好处是一个特征或功能独立于其余的特征或功能，能够实现最优。还有，若是一个特征失败了，不会致使其余的特征也失败，它们之间彼此独立运行，互不影响。这种方法也有助于应用程序的设计和理解，便于复杂的互相依赖的系统的管理。 每一个组件或模块应有单一的责任：每个组件或模块应该负责实现特定的特征或功能。这可使组件实现内聚且更容易优化和变动。 一个组件或对象不该该依赖其余组件或对象的内部细节：组件或对象调用其余组件或对象的方法，这些被调用的方法应该说明如何去使用它。若是须要，将这些内容放在子组件或其余独立的组件中。这将有助于开发一个具备可维护性和适应性的应用程序。 在一个应用程序内部不要复制功能：应该只有一个组件提供特定的功能——这个功能不该该在其余的组件中出现。在一个应用程序中复制功能会使功能的变动很难维护，削弱了程序的条理性，引入了潜在的矛盾。 肯定应用程序组件的组成部分：实现这一点的最好方法是肯定符合你状况的模式，检查这些模式所使用的组件的类型。例如，一个小型的应用程序可能不须要一个业务工做流或者UI进程组件。 组织不一样类型的组件到各自的逻辑层：在一开始，肯定不一样的关注领域，而后组织相互关联组件到合适的逻辑层中。 保持层间设计模式的一致性：在一个逻辑层中，组件的设计对于一类特定的功能应该是一向的，有延续性的。例如，若是你选择使用表数据网关的模式建立对象，你就不该该再使用其余的方式来访问数据和初始化业务对象。 在同一逻辑层中不该混合不一样类型的组件：例如，UI层不该该包含业务进程组件，而应该包括处理用户输入和处理用户请求的组件。 肯定哪类分层要强制执行：在一个严格的分层系统中，A层中的组件不能调用C层中的组件，它应老是调用层B中的组件。而在一个相对宽松的分层系统中，一个层中的组件能够调用其下层中的组件，而不仅是正下层中的组件。在任何状况下，都应该避免对上层的调用和依赖。 抽象实现层间的松散耦合经过定义接口，层内的组件间能够以一种共知的方式彼此进行请求和响应，这样的实现相对比较灵活。另外，你也能够用接口或抽象类来定义公共的接口或者抽取公共的部分（依赖倒置）。 一个组件不要承载太多的功能：例如，一个UI进程组件不该该包括数据访问代码。一种常见的违反模式的状况叫作Blob（一团），在这种状况下，基类提供了过多的功能。一个“团”对象一般有不少函数和属性用来提供混合了日志和异常处理的业务功能。因为要处理子功能的各类变体，作复杂的初始化，这类对象一般很是庞大。最终结果是，这种的设计很容易产生错误，并且很难维护。 清楚组件间是如何通讯的：这首先须要了解你的应用程序是如何部署的。须要明确的是，组件间的通讯是否须要跨越物理边界或跨进程，全部组件是否运行在统一进程当中。 多用组合少用继承：在尽量的状况下，使用组合的方式来重用功能，而不使用继承的方式。由于继承增长了父子类之间的依赖关系，限制了子类的重用。这也减小了继承的层级，避免了去处理复杂的层级关系。 保持层内或组件内数据格式的一致性：混乱的数据格式会使程序很难运行、扩展和维护。每次你都须要在不一样格式间进行转换，执行转换的代码。这样减低了性能，并且没有必要。 尽量的将交叉（横切）代码从业务逻辑中抽象出来：交叉（横切）代码一般涉及到安全性、通讯和操做管理（例如，日志和检测）。将这些代码混合到业务逻辑中会致使程序扩展和维护上的困难。修改这些交叉（横切）代码会牵联到全部混合了它们的业务逻辑代码的修改。能够考虑使用框架来实现交叉（横切）的集中处理。 命名习惯的统一：看看团队、组织里是否创建了相关的命名规定，若是没有，你应该创建一个公用的命名标准。由此而来的代码的一致性会使团队成员检查代码更容易。这样也更易维护。 创建异常处理的标准：例如，应该老是在层的边界捕获异常，不该该在层内捕获异常，除非你能够在层内处理它，也不该该用异常来实现业务逻辑。该标准还应包括错误提示、记录日志的策略和对异常的检测 3、架构框架 下面的表格列出了你在设计架构时应该考虑的主要方面。经过这些关键的问题了解一般会犯错的地方。这个章节为这些不一样的方面提供了指导。 表格1架构框架
认证和受权数据库
缺乏跨信任边界的认证
缺乏跨信任边界的受权
松散或不适当的受权设计模式
缓存缓存
数据缓存反复无常
缓存敏感数据
选择了错误的缓存方式安全
通讯架构
选择了错误的传输协议
多余的跨物理和进程边界的通讯
没有有效的保护敏感数据并发
组合框架
彼此协做的应用模块之间相互依赖使开发、测试和维护变得很困难。
模块间的依赖变动强制代码从新编译和模块的从新部署
顽固的代码依赖使动态的UI布局和更新变得很困难
顽固的代码依赖使模块的动态加载变得很困难函数
并发和事务处理布局
没有保护对静态数据的并发访问
死锁致使不适当的锁定
没有选择适当的并发处理模式
长期保持对数据的锁定
不恰当的使用互锁性能
配置管理
缺乏或存在错误的配置信息
没有对敏感的配置信息采起保护措施
无限制的对配置信息的访问
连接和聚合
错误的功能分组
关注点的分离不清楚
层间的连接过于紧密
数据访问
对总用户的没必要要的验证和受权
多余的对数据库的访问
业务逻辑掺杂数据访问代码
异常管理
处于不稳定状态
向最终用户暴露敏感信息
使用异常控制程序流程
没有记录有关异常足够的细节
分层
对组件进行了错误的分层
没有遵照分层和从属划分的规则
没有考虑层间的物理分布
日志和检测
缺乏日志和检测
日志和检测太过细致
没有将日志和检测作成运行时可配置的
没有阻止和处理日志记录失败的发生
没有对关键的业务进行日志记录
状态管理：
使用了错误的状态存储
没有考虑序列化的须要
没有在须要的时候保持状态
结构：
针对方案选择了错误的结构
建立了一个过于复杂的结构，而这是没有必要的
没有考虑部署方案
用户体验：
没有遵循发布的指导方针
没有考虑易用性
对不相关的函数建立重载接口
验证：
缺乏跨信任边界的验证
没有对范围、类型、格式和长度进行有效的验证
没有重用验证逻辑
工做流：没有考虑管理的需求错误选择工做流模式没有考虑异常状态及对它们的处理