软件架构设计应该考虑的问题(转)

一、架构设计基本原则
　　1、关键点的分离
　　2、单一责任原则
　　3、最少知识原则
　　4、不要重复自己
　　5、避免在前期做大量的设计
　　6、多用组合少用继承

二、设计要点
　　在设计软件或系统时，软件架构的目标就是通过将设计分割为不同的关注领域来降低其复杂性。
　　例如，用户接口、业务进程和数据访问均可视为不同的关注领域。

设置应用程序的指导方针：
　　1、避免在前期做所有的设计
　　2、分割关注领域
　　3、每个组件或模块应有单一的责任
　　4、一个组件或对象不应该依赖其他组件或对象的内部细节
　　5、在一个应用程序内部不要复制功能
　　6、确定应用程序组件的组成部分
　　7、组织不同类型的组件到各自的逻辑层
　　8、保持层间设计模式的一致性
　　9、在同一逻辑层中不应混合不同类型的组件
　　10、确定哪类分层要强制执行
　　11、抽象实现层间的松散耦合
　　12、一个组件不要承载太多的功能
　　13、清楚组件间是如何通信的
　　14、多用组合少用继承
　　15、保持层内或组件内数据格式的一致性
　　16、尽可能的将交叉（横切）代码从业务逻辑中抽象出来
　　　　例如，安全性、通信和操作管理（例如，日志和检测）
　　17、命名习惯的统一
　　18、建立异常处理的标准
　　　　例如，应该总是在层的边界捕获异常，不应该在层内捕获异常，除非你可以在层内处理它，也不应该用异常来实现业务逻辑。
　　　　该标准还应包括错误提示、记录日志的策略和对异常的检测

三、设计架构时应该考虑的方面及常见的问题

1、认证和授权
　　缺少跨信任边界的认证
　　缺少跨信任边界的授权
　　松散或不适当的授权
2、缓存
　　数据缓存反复无常
　　缓存敏感数据
　　选择了错误的缓存方式
3、通信
　　选择了错误的传输协议
　　多余的跨物理和进程边界的通信
　　没有有效的保护敏感数据
4、组合
　　彼此协作的应用模块之间相互依赖使开发、测试和维护变得很困难。
　　模块间的依赖变更强制代码重新编译和模块的重新部署
　　顽固的代码依赖使动态的UI布局和更新变得很困难
　　顽固的代码依赖使模块的动态加载变得很困难
4、并发和事务处理
　　没有保护对静态数据的并发访问
　　死锁导致不适当的锁定
　　没有选择适当的并发处理模式
　　长期保持对数据的锁定
　　不恰当的使用互锁
5、配置管理
　　缺少或存在错误的配置信息
　　没有对敏感的配置信息采取保护措施
　　无限制的对配置信息的访问
6、链接和聚合
　　错误的功能分组
　　关注点的分离不清楚
　　层间的链接过于紧密
7、数据访问
　　对总用户的不必要的验证和授权
　　多余的对数据库的访问
　　业务逻辑掺杂数据访问代码
8、异常管理
　　处于不稳定状态
　　向最终用户暴露敏感信息
　　使用异常控制程序流程
　　没有记录有关异常足够的细节
9、分层
　　对组件进行了错误的分层
　　没有遵守分层和从属划分的规则
　　没有考虑层间的物理分布
10、日志和检测
　　缺少日志和检测
　　日志和检测太过细致
　　没有将日志和检测做成运行时可配置的
　　没有阻止和处理日志记录失败的发生
　　没有对关键的业务进行日志记录
11、状态管理
　　使用了错误的状态存储
　　没有考虑序列化的需要
　　没有在需要的时候保持状态
12、结构
　　针对方案选择了错误的结构
　　创建了一个过于复杂的结构，而这是没有必要的
　　没有考虑部署方案
13、用户体验
　　没有遵循发布的指导方针
　　没有考虑易用性
　　对不相关的函数创建重载接口
14、验证
　　缺少跨信任边界的验证
　　没有对范围、类型、格式和长度进行有效的验证
　　没有重用验证逻辑
15、工作流
　　没有考虑管理的需求
　　错误选择工作流模式
　　没有考虑异常状态及对它们的处理

参考：
http://www.cnblogs.com/feishixin/archive/2009/06/18/1515177.html