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

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件架构设计应该考虑的问题(转)
⼀、架构设计基本原则
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、⼯作流
没有考虑管理的需求
错误选择⼯作流模式
没有考虑异常状态及对它们的处理
参考:。

相关文档
最新文档