软件架构之细化架构阶段

今天主要分享“细化架构”的相关知识及认识理解

• 架构设计的步骤

  • 概念架构，构思关键问题的解决策略
  • 细化架构，以保证为开发提供足够的指导和限制
  • ..........
• 关于“细化架构”的误区
  • “概念架构”和“细化架构”典型差异

    • 接口。在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义（只有抽象的组件和抽象的交互机制）

    • 子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口，只有职责，一般是处理组件
      数据组件或连接组件中的一种。

    • 交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务就是典型的例子

    • 方案=“项目+需求+架构”的总览，但是方案≠架构的全部
  • 架构工作的范围是非常广泛的，需要从多角度，使用多视图的办法设计
• 那“细化架构”是什么
  • “概念架构”对应的是‘概念级’的解决方案，概念架构针对重大需求、特设需求、高风险需求，给出高层次解决方案
  • “细化机构”对应的是“规约级”的解决方案，在该阶段，通常使用多视图的方法来展示架构思想，其特点是：利于思考（分而治之），便于交流（分离了关注点）　　

• 实现“细化架构”的手段
  • 根据温昱将按照温昱思路，推荐使用五视图作为实践的参考（每个视图，一个角度）

　　　　　

• • 逻辑架构：主要工作包括划分子系统、定义接口等，通常借助接口-包图来表述。划分子系统的方法包括分层的细化、分区的引入、机制的提取。

    其相关原则为：职责不同的单元划归不同的子系统；通用性不同的单元划归不同的子系统；需要不同开发技能的单元划归为不同子系统；兼顾工作量的相对均衡，进一步划分太大的子系统（项目管理的80小时原则）.此外，定义接口时一定不能自说自话，需要足够的沟通

  • 运行架构：在涉及大量并发时，需要考虑，不常用。

  • 开发架构：这部分主要是开发语言、相关框架的选择，项目文件的结构和形式，在实际中很重要，统一和合理的结构可以大幅提升在软件开发中，维护成本实际上是最大的，因此合理的重用非常重要

  • 物理架构：这部分的思维重点是"开销"和争用"，因此架构的目标就是降低开销和避免征用
  • 数据架构：数据的分布方案是一个难点，通常可以借助一下6个策略

本博客为学习温昱《一线架构师实践指南》的“细化架构”学习总论，之后会详细介绍“五视图”的策略