架构设计方法论笔记

1、什么是方法论
        教怎么做架构设计
2、什么是设计
        - 实现意图的书面变现形式，而非口头东西
        - 让实现者能理解设计者的意图
        - 让不同的实现者做出来的东西差不多
        - 设计是严肃的，后续实现者不能随意偏离设计
3、什么是架构
        - 内部边界划分、功能联系、通讯协议等

参考资料 - 《软件工程》《软件方法》《架构实战》

一、业务分析 - （系统要支撑的业务是怎样的）为什么对象提供什么的服务

    1、业务分析概述：
        - 搞清楚该业务领域的概念以及业务的运转过程；
        - 系统的目的为了优化业务流程，使业务运转的更加高效、经济；
        - 系统价值在于实施后能够帮助客户带来多少业务价值；
        - 不管有无系统，业务通常是不变的；
    2、业务分析阶段活动模型

        - 业务分析师：市场、产品、研发共同完成
        输出一份大家都能看的懂的材料    
        2.1 领域模型：概念类或者现实世界中对象的可视化表示；又称概念模型、领域对象模型、分析对象模型。专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
        - 举例：

      业务分析阶段更多的是关注与业务，而不是关注于系统代码如何实现。
      领域模型常见的错误 1：将待开发系统也画到领域模型内 2：概念划分不清，关系不够明确没有画到位（需要关注于实体 属性 关系）

      领域模型的用途 1：理解业务中的概念关系 2：指导数据库设计 3：指导系统设计 4：指导开发

      2.2 业务对象

        1：业务执行者（business actor） 使用组织所提供业务的人 - 服务对象

        2：业务工人（business worker） 提供业务的组织的内部支撑人员 - 工作者

        3：业务实体（business entity）提供业务的组织的内部信息系统 - 不一定是电子化的，包含硬件等

         2.3 业务用例 组织对外提供的业务服务能力，针对于业务执行者与业务工人的相关动作

         2.4 业务流程 现状-->系统实施后

        业务流程分析的意义：动态表达业务流转过程；很好的理解业务才能做出更好的设计；通过比对前后差异，分析优化点，评估体现系统价值

二、需求分析 - （系统在业务中要做什么）

1、需求分析阶段活动模型

 其中

        领域模型与业务模型在业务分析阶段完成，

        需求调研成果包含市场、产品调研后产生的一些需求。需求分析阶段更多的是针对系统所提出的

        系统分析师通常由架构师与产品经理共同担任，主要输出相关文件

        系统上下文是指系统周边的关系。系统依赖的其他系统

        系统用例是指系统所使用的案例，由业务用例所推导出的用例。使用动词短语命名如添加用户、查询话费等。右图更加规范

        业务用例与系统用例的区别与联系：

        业务用例是描述组织对外提供的能力，系统用例是描述系统对外提供的能力；

        系统用例是业务用例相应流程中对系统的操作。

        功能与用例的区别：

        用例是需求分析的产物，描述的是用户使用系统完成什么业务；是动态的（动词短语） 如 查询名称

        功能是设计阶段的产物，根据系统用例和架构推导出来的；是静态的（名词短语） 如 名称查询

        常见错误：描述需求是给出的是一份功能清单，而不是用户通过系统完成的业务

        非功能设计

        可用性（系统的高可用）、

        性能（关键重要用例的拆分如支持的并发、TPS等）、

        安全性（鉴权、数据安全）、

        可扩展性（业务或者系统未来可能变动大、与其他系统对接）、

        可伸缩性（加硬件提高性能、减硬件降低性能）、

        可移植性（移植到国产系统等）、

        经济性（研发投入、服务器投入、运维投入）

示例：

三、架构设计 - （系统总体上怎么做）

系统简单时：

        概要设计

        详细设计

系统复杂时：

        架构设计 (宏观层面，减少变更带来的代价太大)

        概要设计

        详细设计

组件、功能、模块之间的区别和联系

        1、组件是架构设计考虑的单元

        2、功能与模块是概要设计与详细设计考虑的单元

        3、一个组件可能包含多个模块、涉及多个功能

        4、一个功能的实现可能需要多个组件的相应模块共同协作完成

         组件太多时需要分层，web层、应用层、服务层、数据层

        什么是架构：系统内部组件的关系

架构设计阶段的活动模型

 架构设计好坏的衡量标准：

• 设计完成时 设计资料的规范性、思路决策技术选型的合理性、关系是否合理
• 系统实现后 功能需求与非功能需求的满足程度

1、逻辑架构

• 将系统分成若干个逻辑组件并建立它们之间的关系，以满足系统需求。静态关系用组件图，动态关系用序列图
• 不涉及技术元素，纯概念的表述
• 读者可以是非技术人员

2、物理架构

• 将逻辑架构中的组件转成技术性的物理组件，组件使用英文，在实现时需要遵循这些命名
• 物理架构粒度有大有小，可表现为子系统、进程、对象等多种形式（打包方式、系统之间的协议）
• 还需解决非功能性需求
• 与后续设计和实现做衔接
• 非技术人员可能难以看懂

四、概要设计与详细设计

1. 概要设计
   • 功能模块划分（功能一览表）来源于系统用例
   • 接口设计（以上划分出来的模块之间的接口，功能概要、接口名、参数、返回值等）

   

    2、详细设计

                1.模块内部功能实现逻辑描述

                2.界面设计

                3.数据库设计