DAY1-系统设计方案论笔记

今天的理论课对我来说都是全新的知识点，消化起来有点慢。

总结就是，输入：项目需求，输出：系统设计方案。

那么要实现从输入到输出，需要掌握的知识和技巧有下面这些：

一、需求分析技巧

（一）结果：

1.用户通过网站注册并登录；2.车次、车厢、经停站、时刻表增删改查；3.修改个人信息；4.乘客管理；5.余票管理；6.创建（票）订单；7.第三方支付（支付宝）；8.支付成功通知（MOCK）。

（二）知识和技巧：

1.需求分析是理解和挖掘用户的诉求，以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。

2.梳理边界（哪些做哪些复用）、用户故事（查票，付钱，完成订单，收到通知）和用户路径（操作路径尽可能的短）

分析背后的人性：人性是提出需求的本源

需求产品化：模块化、配置化、有逻辑

需求落地路径：需求分析-》可行性-》设计-》编码-》测试-》发布

3.应对伪需求：没有调研、没有目标、没有逻辑的无脑需求

用数据化结果否定需求合理性

用正反案例来说明需求需要改进的地方

用户路径和触点推演需求合理性

4.应对权利需求：老板或者是强势业务方的需求

先肯定需求价值再提出需求实现的成本

给出更好的需求替代方案

从数据和案例角度说明需求快速上线的危害性

5.问题的分层：

（本源问题）用户问题：我想支付

（经营视角）业务问题：支持一切可以支付的第三方支付工具

（体系结构）产品问题：支付需要逆向流程、异常流程、对账模块等

（架构代码）技术问题：高并发、可用性、实现第三方支付的链路

6.KISS原则：Keep it simple and smile

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

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

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

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

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

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

成本部门的挑战（ROI问题）

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

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

7.DRY原则：Don't Repeat yourself

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

重复代码的危害性：不一致性、代码冗余、易出BUG

二，模块设计原则

（一）七大设计原则：提升软件的可扩展性，可维护性。是抽象思维和归纳思维的集中体现

1.单一职责：高内聚、低耦合的延伸，属性和行为向着模块预先定义的功能内聚

2.里式替换原则：父类能够出现的地方，子类一定能够出现；而子类出现的地方，用父类去代替，一般都有问题

3.接口隔离原理：接口的粒度尽可能的小，统一接口的方法强内聚于同一特征

4.组合复用原则：组合是一种松散的合作关系，组合产生的对象，方法暴露的少

5.依赖倒置原则：细节依赖抽象，底层依赖于高层

6.迪米特原则：最少认知原则。相互了解的信息，尽可能的少。使用接口只需了解输入输出即可，不需要关注具体代码实现

7.开闭原则：对扩展开放，对修改关闭。扩展能力主要是对需求继续变化的适应能力，一旦成功运行，就不应该改具体的代码；扩展通过依赖倒置，实现增加类，或者模块的方式，实现需求的变化。任何变化的掉，都是需要被隔离出来的。

（二）实践点：类图设计、接口设计、组合设计

三、架构设计目的

确定系统边界（在技术层面上做与不做）；

确定各个模块之间的依赖关系（模块的宏观输入与输出）；

确定后续的子系统或模块设计的演进方向（在一个既定的框架内和技术方向上）；

确定非功能性需求（安全性、可用性、可扩展性等）。

（一）拓展知识：

1.什么是架构？

架构是一种能力，而不是一个职位

架构=组成+决策；组成=模块结构+模块关系；决策=约束+设计原则+演化方向

2.如何画架构图？

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

确定架构中的关键要素（比如产品、技术、服务）

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

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

3.如何判断架构图的好坏

布局：图形的上线左右前后6个方向的位置关系

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

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

4.架构图的分类

业务架构：使用一套方法论，对所涉及到的业务单元进行边界划分。熟悉业务

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

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

5.传统架构图：4+1

物理视图：和部署相关的架构决策（一般不画）

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

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

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

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

6.UML：Unified Model Lannguage 统一建模语言

使用图形和符合描述软件模型中的各个元素和他们之间的关系

6.1分类：

静态结构图：类图、对象图、包图、组件图、部署图

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

6.2类的六大关系：

泛化关系：即继承关系

实现关系：实现接口

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

组合关系：业务上整体与部分不可以分开，是关联关系的特例

依赖关系：只要在类中用到了对方，就存在依赖关系

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

6.3时序图：

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

关注正常流程，不关注逆流程，不关注异常流程，不关注分支判断

7.架构图：

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

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

（二）项目介绍：T31项目是类似于12306的售票网站

从查票、下单、付钱、通知的主流程

抽象商品、订单、支付的核心模型

处理票务异常和日志

了解架构设计背后的方法论

以战促练，全面提升大家的代码能力、设计能力、交付能力和协作能力。