【架构】软件架构决策验证标准

为什么需要软件架构

• 把架构视为交流工具
• 对项目规划实施影响力
• 关注非功能方面能力；
• 与设计团队做出约定；
• 为影响力分析提供支持；

企业视图：确定企业中业务流程、数据资源、信息资源、技术、面向客户的用户界面已经传输渠道，并把他们全都表示在同一张视图中。
分层视图：
IT企业视图：
架构决策
验证方式：
1）完整性：如果把某个组件放入架构中，那么该组件应该要能够维持总体架构的完整性，而不应去破坏或损害架构中的某些方面；
2）完备性：每个架构组件所具备的特征应该都得到描述和定义；
3）包含度：每个架构组件都应该位于且只能够位于架构中的某一层里；
4）有效性：要证实某个架构组件能够像预期的那样进行运作；
5）可靠性：每个架构组件都应该能在各种使用情景下运作，而且能够协调一致的运作；
6）独立性：每个架构组件都是可以分开对待的。
7）灵活性：架构组件应该能够与其他组件相集成，并且能够运用在不同的情境中；

功能模型： CBM矩阵（组件的协作，组件职责矩阵）
一个子系统可以封装一个或多个组件。
一个组件可以公布一个或多个接口；
一个接口可以公布一个或多个操作；
与一个或多个数据实体进行交互的职责，可以有组件来负担；

把各组件安排到适当的架构分层中；
物理层面组件
逻辑层面组件

操作模型：是提供一张蓝图，以演示功能组件在运作时所必须的一套网络、服务器、计算测试平台。

集成：
集成层面：
用户界面，
数据层面，
面向消息集成，
基于API的集成（同一个功能，多个实现；把多个功能合并成一个业务流程 BPM），
基于服务的集成
集成模式：
同步请求-响应模式
批次模式
同步批次请求-应答模式
异步批次请求-应答模式
存储并转发模式；
发布-订阅模式；
聚合模式；
管道与过滤模式；
消息路由模式；
消息转换器模式；