孤尽-架构设计-day01

需求分析
理解和挖掘用户的诉求 以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责 模块的过程。（根据用户提出所求分析切实可行有逻辑有意义的需求）

注意点：

边界：区分可复用的功能模块，明确真正需要自行开发的功能模块

用户故事：区分各类用户的功能模块

用户路径：用户使用功能模块的操作步骤流程（目标：尽量简化操作流程）

合理处理伪需求和权力需求

扩展概念

PMF（product market fit）:市场产品契合度（eg：某些功能对于目标用户没有对应的必要性占比较高，则说明该功能是无效需求）
项目基本需求分析
用户通过网站注册并且登录
车次、车厢、经停站、时刻表增删改查
修改个人信息
乘客管理
余票查询
创建(票)订单
第三方支付(支付宝)
支付成功通知(MOCK)
问题的分层
（本源问题）用户问题

（经营视角）业务问题

（体系结构）产品问题

（架构代码）技术问题

KISS原则
Keep it simpe and smile

simple

架构的理念是大道至简：解决问题

如何让我们的系统有可扩展性和可维护性

如何让我们的系统能够恰到好处地解决问题

如何让我们的系统能够运行3-5年不重构

拓展概念

逆向流程（eg：如何退款）
smile

现代软件需要很强的协调能力，保持微笑，迎接各种否定。

业务部门的挑战（价值问题）

成本部门的挑战（ROI “投入产出比” 问题）

测试部门的挑战（可测试性）

技术部门的挑战（可行性和工期）

DRY原则
Don’t Repeat yourself

一切重复的代码都可以抽象

重复代码的危害性

不一致性

代码冗余

易出BUG

七大设计原则
共同点：提升软件的可拓展性，可维护性是抽象思维和归纳思维的集中表现。

实践点

类图设计

接口设计

组合设计

单一原则

里氏替换原则

接口隔离原则

组合复用原则

依赖倒置原则

迪米特原则

开闭原则

对扩展开放,对修改关闭
架构师最大的难点:识别和隔离变化点

拓展概念

熵增定律

熵∶反映自发过程不可逆性的物质状态指标，熵是衡量我们这个世界中事物混乱程度的一个重要指标。一个孤立系统总是存在从有序度转变成无序的趋势。

开闭原则是熵减

对抗熵增的最好方式是熵减。熵减最重要的是形成开放性

开放性设计是系统能够有序接纳外部能量的能力。在软件领域我们的外部能量指的是需求的多变和业务的不断试错。

架构与架构图
什么是架构
架构是一种能力，不是一个职位

架构 = 组成 + 决策

组成 = 模块结构 + 模块关系

决策 = 约束 + 设计原则 + 演化方向

架构的目的
确定系统边界,在技术层面上做与不做

确定系统里各模块之间的依赖关系与模块的宏观输入与输出

使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化

明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等

如何画架构图
搞清楚要画的架构图的类型

确认架构图中的关键要素(比如产品、技术、服务)

梳理关键要素之间的关联:包含、支撑、同级并列等

输出关联关系清晰的架构图

拓展概念

架构图：水平面上的业务模块 + 垂直面上的技术模块 互相依赖形成的逻辑结构图
架构图的好坏
布局：图形的上下左右，前后6个方向的位置关系（层次堆叠）

颜色：视觉中心在哪里，哪些元素被忽略

逻辑：组件之间的依赖，业务实现的可行性

架构图的分类
业务架构

使用一套方法论,对所涉及到的业务单元进行边界划分

eg：团购网站系统 -> 商品类目,订单服务,支付,退款等进行清晰划分

应用架构

对整个系统的实现进行可视化落地实践，系统的层次/开发原则/各个层次的应用服务，一般为垂直依赖型。

eg：团购网站系统 -> 数据层,服务层,通讯层,展现层。

数据架构

是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景,对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。

考虑点：系统需要什么样的数据?如何存储这些数据?如何进行数据架构设计

技术架构

承接应用架构的技术需求,并根据识别的技术需求,进行技术选型,把各个关键技术和技术之间的关系描述清楚。

传统架构图（4+1）

物理视图：和部署相关的架构决策

逻辑视图：设计满足功能需求的架构（逻辑结构图）

开发视图：设计满足开发期质量属性的架构（UML图）

处理视图：设计满足运行期质量属性的架构（UML图）

场景视图：需求分析技术，通常采用UML的用例图进行设计

UML（Unified Model Language）
定义：统一建模语言,使用图形和符号描述软件模型中的各个元素和他们之间的关系
UML的分类
静态结构图：类图、对象图、包图、组件图、部署图

动态行为图：交互图(时序图与协作图)、状态图、活动图

类的六大关系
泛化关系（继承关系）

实现关系（实现接口）

聚合关系（业务上整体与部分可以分开,是关联关系的特例）

组合关系（业务上整体与部分不可以分开,同样是是关联关系的特例）

依赖关系（只要在类中用到了对方,就存在依赖关系）

关联关系（体现的是业务逻辑的关系,是依赖关系的特例,具有导航性&多重性）

类图
类图（Class diagram）是显示了模型的静态结构,特别是模型 中存在的类、类的内部结构以及它们与其他类的关系等

时序图
通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作

关注正常流程

不关注逆流程

不关注异常流程

不关注分支判断

架构图
架构图是表达这种集合的载体,是水平的业务单元+垂直的技术单元组成的逻辑结构图

作用：将目标系统的结构可视化,通过直观的方式描述技术思维减少沟通障碍,提升协作效率划分目标系统的边界。