Day1-架构设计

一、需求分析

• 边界：能否复用代码。
• 用户故事：需要面对的是用户的诉求而不是KPI诉求。
• 用户路径：尽可能短。

1、问题分层

• 用户问题：即本源问题，要做什么
• 业务问题：从经营视角出发，拆解用户问题，并分析制定方案
• 产品问题：即体系结构，需考虑逆向、异常流程
• 技术问题：即架构代码，考虑技术工具，方案，解决难点

2、KISS原则

• Keep it simpe and smile
• 架构理念是大道至简，目的就是解决问题

3、DRY原则

• Don’t Repeat yourself

二、设计原则

• 单一原则：高内聚、低耦合，模块名称很重要
• 开闭原则：对扩展开放对修改关闭，是一个熵减的过程
• 里式替换：父类能出现的地方子类一定能够出现
• 依赖倒置：接口的粒度尽可能小，同一接口的方法强内聚于同一特征
• 接口隔离：细节依赖抽象
• 迪米特：互相了解的信息尽可能少，只关注输入输出，不需关注实现
• 组合复用：继承是绑定关系，组合相对较为松散，避免接口污染

三、什么是架构

• 架构是一种能力，而不是一个职位
• 架构 = 组成 + 决策
  组成 = 模块结构 +模块关系
  决策 = 约束 + 设计原则 + 演变方向
• 难点：识别和隔离变化点

1.架构图

定义

• 水平面上的业务模块+垂直方向上的技术模块互相依赖，形成的逻辑结构图。

好坏

• 布局+颜色+逻辑

分类

• 业务架构
• 应用架构
• 数据架构
• 技术架构

传统架构图4+1

• 物理视图： 和部署相关的架构决策（一般不画）
• 逻辑视图： 设计满足功能需求的架构（逻辑结构图）
• 开发视图： 设计满足开发期质量属性的架构（UML图）
• 处理视图： 设计满足运行期质量属性的架构（UML图）
• 场景视图： 需求分析技术，通常采用UML的用例图进行设计

UML

Unified Model Language:
Unified： 说明以前不统一
Model： 建模往往需要抽象
Language： 交流，为啥能够交流，定义共同的协议！
统一建模语言，使用图形和符号描述软件模型中的各个元素和他们之间的关系

UML的分类：

• 静态结构图：类图、对象图、包图、组件图、部署图
• 动态行为图：交互图（时序图与协作图）、状态图、活动图

类图的六大关系

• 泛化关系：即继承关系
• 实现关系：实现接口
• 聚合关系：业务上整体与部分可以分开，是关联关系的特例
• 组合关系：业务上整体与部分不可以分开，同样是是关联关系的特例
• 依赖关系：只要在类中用到了对方，就存在依赖关系
• 关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性

时序图

• 通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
• 关注正常流程
• 不关注逆流程
• 不关注异常流程
• 不关注分支判断

PS

• PMF是Product Market Fit的简写，是指产品和市场达到最佳的契合点，你所提供的产品正好满足市场的需求，令客户满意。
• ROI：Return On Investment，投资回报率。
• 熵增定律：一个独立的系统必定会从有序慢慢变成无序。