2 重要原则
2.1 架构风格
- 架构风格(architectural style)，也叫架构模式(architectural pattern)，为一组系统定义了抽象的框架
- 架构风格内容包括
- 提供组件和连接者的词汇表，以及它们如何联合的规则
- 通过给出常见问题的解决方案改善划分，允许设计重用
- 描述一种特别的方式来配置一组组件(一个具有定义良好的接口、可重用、可替换的模块)和连接者(模块之间的通信链接)
- 每种风格描述了一个系统分类，包括
- 一组组件类型，用来执行系统要求的功能
- 一组连接者(子例程调用，远程过程调用，数据流和套接字)使得不同的组件通信、协调、合作
- 语义限制，定义组件如何整合成系统
- 组件的布局拓扑图，表明它们运行时的相互关系
2.2 公共的架构设计
架构风格根据主要的聚焦点可以分为
- 通信
- 消息总线：规定软件系统的使用，通过一个或多个通信通道可以接受和发送消息
- 服务导向架构：定义应用服务使用约定和消息暴露和消费功能
- 部署
- 客户端/服务端：将系统分为客户端和服务端，客户端向服务端发送请求
- 3/N 层式：将功能分为独立的部分，每个部分成为一层，分布在不同的物理机上
- 领域
- 领域驱动设计：聚焦于模块化一个业务领域，基于该领域的实体定义领域目标
- 结构
- 基于组件：将应用设计成可复用的功能或逻辑组件，组件具有定义良好的通信接口
- 分层：将应用的问题分成重叠的组(层)
- 面向对象：基于应用或系统的责任分成对象，每个对象包含数据以及和该对象有关的行为
2.3 架构类型
从企业的角度来看有一下几种架构
- 业务架构：定义企业内业务、管理、组织和主要业务流程的策略，集中于业务流程的分析和设计
- 应用(软件)架构：作为单个应用系统的蓝图,系统的相互作用和系统对组织业务流程的的关系
- 信息架构：定义逻辑和物理的数据资源和数据管理资源
- 信息技术(IT)架构：定义硬件和软件的基石，它们组成了组织的整个信息系统
2.4 架构设计流程
- 架构设计流程致力于分解系统为不同的组件，以及组件直接相互作用以满足功能性和非功能性的需求
- 架构设计的输入是
- 通过分析人物得到的需求
- 硬件架构(系统架构配置硬件架构，软件架构反过来为系统架构提供需求)
- 架构设计的输出是一个架构描述
- 架构设计流程包括
- 理解问题：许多软件项目和产品是失败的，因为它们没有真正解决一个有效的商业问题，或者说对于投资没有一个可识别的回报
- 确认设计元素和它们的关系
- 为定义系统的边界上下文设定一个基线
- 基于功能将系统分解成主要的组件。分解可以模型化，使用设计结构矩阵(DSM, Design structure matrix)，它展示了设计元素之间的依赖，不指定元素的粒度
- 评估架构设计
- 评估每个质量参数收集定量的数据和测量，从而评估设计
- 如果满足每个质量参数的标准，则软件设计流程完成
- 否则进入下个阶段，即转换架构设计
- 转换架构设计
- 修改架构直到满足质量参数需求
2.5 重要的架构原则
- 为了改变而构建，而不是为了持续而构建：随着时间发展应用可能需要改变来满足新需求或挑战
- 降低风险和模型以便于分析：使用决策工具，可视化、模型化系统来捕获需求，设计决策
- 使用模型和可视化作为通信和协作工具：和利益共享者高效的沟通和共享设计
- 使用增量迭代的方法：以基本架构开始，然后通过迭代测试逐步形成候选的架构，改善架构
2.6 重要的设计原则
- 关注点分类：确保组件功能之间没有重叠；高内聚，低耦合
- 单一责任原则：系统的每个模块有专门的功能
- 最少知识原则：每个组件或对象不应知道其他组件的内部细节，可以避免依赖性，提高可维护性
- 最小化提前大型设计：当应用需求不明确时，尽量减少大型设计。如果可能需要修改需求，那么避免为整个系统添加大的设计
- BDUF(Big Design Up front)，一种软件开发方法，即程序实现开始之前，程序设计时完全的、完美的、常应用域瀑布模型
- 不要重复功能：重复功能的代码不易修改，清晰度降低，且增加了潜在的不一致性
- 重用功能时使用复合而不是继承：继承增加了父类和子类的依赖性，不利于单独使用子类
- 确定组件并且整合到逻辑层：将某个关注点相关的组件组合到一个逻辑层
- 定义层之间的通信协议
- 定义层的数据格式：不同的组件通过数据格式交互，确保层内的数据格式是一样的
- 系统服务组件应是抽象的：有关安全性、通信或系统服务(比如日志、分析和配置)的代码再各个组件应该是抽象的。不要将其与业务逻辑混合
- 设计异常和异常处理机制：提前定义异常，帮助组件管理错误和不希望的情形
- 命名规范：提前定义命名规范。以便用户理解系统，也便于团队成员检验其他人的代码，增强可维护性