• 读书笔记《一线架构师》


    架构要分阶段,而后分视图:

    1. 把握需求特点,确定架构驱动力(预备架构)
      1. 采用 二维需求观 来定出需求特定和非功能性需求优先级、取舍
      2. 根据重大需求,确定概念架构(概念架构)
      3. 细化架构设计,关注不同视图(4+1视图)
        1. 逻辑视图
        2. 开发视图
        3. 运行视图
        4. 数据视图
        5. 物理视图
        6. *贯穿如上3过程的有*对非功能目标的考虑

    关注约束,要乘早。

    架构设计,除了关注架构本身外,还关注到人,比如,划分子系统原则中,有如下:

    1. 职责分离原则
    2. 通用专用分离原则
    3. 技能分离原则(关注到了人)
    4. 工作量均衡原则(关注到了人)

    ************预备架构***********

    预备架构关注质量因素和相互冲突关系,需要谨慎做出权衡。

    质量点:

    1. 持续可用性
    2. 性能
    3. 可扩展性
    4. 安全性
    5. 可互操作性
    6. 可维护性
    7. 可移植性
    8. 可靠性
    9. 可重用性
    10. 鲁棒性
    11. 可测试性
    12. 易用性

    共同决定架构的因素有:

    1. 功能需求
    2. 质量属性
    3. 约束(4大类约束)
      1. 业务环境
      2. 使用环境
      3. 构建环境
      4. 技术环境

    预备架构,需要:

    1. 建立需求理解的大局观
    2. 关键需求决定架构
    3. 其余需求验证架构

    还需要:

    1. 分析业务需求和约束背后的衍生需求
    2. 发现遗漏需求
    3. 确定关键功能
    4. 确定关键质量
    5. 权衡质量属性之间的矛盾关系

    通过如下分析工具来进行(需求二维视图):

    功能需求(广义)

    质量需求

    约束

    组织级

    用户级

    开发级

    Tip:

    1. 关键功能子集(减法)
    2. 重点支持哪些质量属性(减法)
    3. 充分考虑约束(加法)

    预备架构的分析步骤:

    1. 需求结构化
      1. 采用二维需求视图
      2. 分析约束影响
        1. 采用二维需求视图
        2. 确定关键质量(各质量间的关系、优先级、取舍)
          1. 分类合适+必要扩充
          2. 考虑多方涉众
          3. 检查性思维
          4. 识别矛盾+划定优先级
          5. 严格程度要符合领域和规模特定(比如医疗、航空领域,可靠性极高)
          6. 确定关键功能
            1. 核心功能
            2. 必做功能
            3. 高风险功能
            4. 独特功能

    产出

    ·        关键质量、优先级

    ·        关键功能

    **************概念架构***********

    概念架构针对重大需求、特色需求、高风险需求的要求,给出高层次的解决方案(大方针,非细节)

    分3个步骤:初步设计、高层分割、考虑非功能需求

    初步设计:

    1. 发现关键职责(基于关键功能)
    2. 使用鲁棒图

    高层分割(复杂性是根本问题,虽无法降低,但可以控制):

    1. 切系统为系统
      1. 当系统覆盖的功能范围比较广泛时
      2. Or
      3. 当系统需要部署在复杂的硬件环境中时
      4. 切系统为子系统
        1. 分层方式(以下技术可以同时应用于系统中)

                                                                   i.      Layer(逻辑层)

                                                                  ii.      Tier(物理层)

                                                                  iii.     按通用型分层

                                                                  iv.     技术堆叠

    1. 考虑非功能需求
      1. 采用 目标-场景-决策表 来分析
      2. 目标

         场景  决策
         可重用性    
         持续可用    
         安全性    
      3. 上面的目标列具体内容,是从预备架构中得出的

    产出

    ·        系统分层图及外部系统的表示

    ·        其他表示法,尚不清楚,比如黑板,微内核等

    ****************细化架构***********

    细化架构分5种视图:

    ·        逻辑架构视图

    ·        开发架构视图

    ·        数据架构视图

    ·        运行架构视图

    ·        物理架构视图

    逻辑架构视图

    1. 3管齐下,综合应用
      1. 分层的细化是划分子系统的必用策略之一
      2. 分区的引入

                                                                   i.      对大多数团队而言,应先做一个高级的广度设计,然后马上转到深度优先的底层设计和实现上去

    1. 机制的提取

                                                                   i.      机制是一种特殊的子系统,比如Event Framework

    1. 4 原则
      1. 职责不同的单元划归到不同子系统
      2. 通用型不同的单元划归不同子系统
      3. 需要不同开发技能的单元划归不同子系统
      4. 兼顾工作量的相对平衡,进一步切分太大的子系统
      5. “分”是手段,“合”是目的。不能“合”在一起支持更高层次功能的模块,又有何用呢?
      6. 协作决定接口 – 序列图
      7. 质疑驱动
        1. 功能方面,特殊的功能支持吗?
        2. 质量方面,耦合性、重用性、性能等怎么样?
        3. 用循环思维

                                                                   i.      找遗漏对象事物

                                                                 ii.      通过序列图分析

    1. 10条经验
      1. 划分子系统:分层的细化
      2. 划分子系统:分区的引入
      3. 划分子系统:机制的提取
      4. 接口的定义:协作决定接口
      5. 选用序列图,杜绝协作图
      6. 包 - 接口图:从结构到行为的桥
      7. 灰盒包图:描述关键子系统
      8. 循序渐进的螺旋思维
      9. 设计模式:包内结构
      10. 设计模式:包间协作

    产出

    ·        分层UML图

    ·        关键子系统联系图(包间结构图、灰盒包图)

    ·        关键功能协作图

    物理架构视图

    思维框架

    经济性,技术可行性,易维护性,性能,持续可用性,可伸缩性

    目标层

    通信开销(网络争用),计算开销(内存争用,硬盘争用,CPU争用,数据争用)

    思维层

    软件单元,数据单元,网络,物理节点

    结果层

    产出:

    ·        部署图

    运行架构视图

    1. 控制流图,主动对象<<active>>版型,UML
    2. 如果存在多个控制流,看情况,是否需要
      1. 控制流的create,destroy
      2. 共享内存
      3. 共享消息

    产出

    ·        分层中主动对象标识出

    ·        关系到主动对象的活动流

    开发架构视图

    重用的目标:时刻关注节省成本

    重用价值:重用次数*单次价值

    维护是最昂贵的环节,要重用测试

    重用技术方向:Framework, Service, Server,平台,中间件

    产出

    ·        要编写的源程序清单

    ·        可重用的框架、库

    ·        项目划分、依赖关系

    ·        项目目录结构

    ·        技术选型

    数据视图

    数据分布策略:

    1. 把握系统特点,确定分布策略(合适原则)
    2. 不同分布策略,可以综合运用(综合原则)
    3. 从“对吗”,“好吗”两方面进行评估优化(优化原则)

    数据分布分类:

    1. 独立、集中
    2. 分区(水平、垂直)
    3. 复制、子集
    4. 重组(统计性重组、结构性重组)

    **************各个架构阶段的比较**********

    架构设计应进行到何种程度

    1. 应为开发人员提供足够的指导和限制(可支持并行的详细设计)
    2. 因项目、开发团队情况的不同而变化(项目熟悉程度、风险高低、团队技能水平)
    3. 业务层、通用机制应更深入的设计
      1. 核心模型影响可扩展性,应当深入设计
      2. 通用机制影响易理解性和bug率,应当更深入设计

    概念架构和5视图法的区别和联系

    1. 概念架构从少数视角重点视角进行概念设计
    2. 细化架构从多个视角、全面视角进行充分设计
    3. 经过细化架构设计后,就能进入详细设计了

    工具:场景 – 设计决策

    场景

    设计决策

  • 相关阅读:
    SpringMVC 注解大全
    Maven实战--- dependencies与dependencyManagement的区别
    SpringMVC5.2.0 使用到 WebDataBinderFactory.createDataBinder 方法的类
    Spring DataBinder
    mysql 查询主键外键
    objectMapper.canSerialize SpringMVC实体转JSON字符串
    整合SSM时启动Tomcat报nested exception is java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/exc/InvalidDefinitionException
    synchronizeOnSession
    init-method afterPropertiesSet BeanPostProcessor 执行顺序
    SpringMVC中重定向参数的使用以及原理解析 RedirectAttributes
  • 原文地址:https://www.cnblogs.com/aarond/p/Archtecture.html
Copyright © 2020-2023  润新知