为什么需要软件架构
- 把架构视为交流工具
- 对项目规划实施影响力
- 关注非功能方面能力;
- 与设计团队做出约定;
- 为影响力分析提供支持;
企业视图:确定企业中业务流程、数据资源、信息资源、技术、面向客户的用户界面已经传输渠道,并把他们全都表示在同一张视图中。
分层视图:
IT企业视图:
架构决策
验证方式:
1)完整性:如果把某个组件放入架构中,那么该组件应该要能够维持总体架构的完整性,而不应去破坏或损害架构中的某些方面;
2)完备性:每个架构组件所具备的特征应该都得到描述和定义;
3)包含度:每个架构组件都应该位于且只能够位于架构中的某一层里;
4)有效性:要证实某个架构组件能够像预期的那样进行运作;
5)可靠性:每个架构组件都应该能在各种使用情景下运作,而且能够协调一致的运作;
6)独立性:每个架构组件都是可以分开对待的。
7)灵活性:架构组件应该能够与其他组件相集成,并且能够运用在不同的情境中;
功能模型: CBM矩阵(组件的协作,组件职责矩阵)
一个子系统可以封装一个或多个组件。
一个组件可以公布一个或多个接口;
一个接口可以公布一个或多个操作;
与一个或多个数据实体进行交互的职责,可以有组件来负担;
把各组件安排到适当的架构分层中;
物理层面组件
逻辑层面组件
操作模型:是提供一张蓝图,以演示功能组件在运作时所必须的一套网络、服务器、计算测试平台。
集成:
集成层面:
用户界面,
数据层面,
面向消息集成,
基于API的集成(同一个功能,多个实现;把多个功能合并成一个业务流程 BPM),
基于服务的集成
集成模式:
同步请求-响应模式
批次模式
同步批次请求-应答模式
异步批次请求-应答模式
存储并转发模式;
发布-订阅模式;
聚合模式;
管道与过滤模式;
消息路由模式;
消息转换器模式;