20211026 开课吧T31 day1 架构设计笔记

文档格式什么的， 觉得超级麻烦。
T31训练营项目介绍
“类似12306的购票网站， 从查票、下单、付款、通知的主流程， 抽象商品、订单、支付的核心模型； 处理票务异常和日志， 了解架构设计背后的方法论； 以战促练，全面提升代码能力、设计能力、交付能力和协作能力”

day1 需求、架构设计篇

主要是听孤尽老师讲了一些需求、架构设计方面的内容，以及一些学习方法，知识树等。收获极多！

1、 需求分析
在需求分析层面， 我们需要在理解需求的基础上， 站在客户角度、业务角度综合分析提出需求的各个用户述求及背后的逻辑。 转换成可行性的分析结果， 从非结构化的寥寥数语的原始需求中， 结构化、系统化我们需要确定的系统职责、模块的过程。
每个需求都是人来提出， 存在即是道理。 背后的根源是人性的述求，需求提出人为什么要做这个事情？ 监管？绩效？理想等等， 我们站在这个人性的基础之上， 将需求产品化：“模块化、配置化、有逻辑”，就是我们要提供功能入口， 用户需要做什么操作能够达成我做这个操作想达到的目的。
在需求理清之后， 我们评估需实现的可能实现技术栈，结合现有系统或者准备新建的系统预估工期跟需求要求达成的时间进行比对，进行可行性分析、然后进入设计、编码、测试、发布的后续流程。
在我们碰到的需求里， 会有伪需求及权力需求的存在， 在应对上，对于伪需求， 我们可以用数据化的结果来否定需求的合理性；用正反案例来说明需求需要改进的地方；在用户路径和触点推演需求合理性。对于权力需求， 我们要第一时间响应boss的要求， 再提出需求实现成本，进一步给出更好的需求替代方案。 对于要求快速上线的需求， 从数据和案例角度说明需求快速上线的风险有多大。
2、 设计原则
在我们对需求或者问题分析的时候， 需要明白的概念有 用户问题、业务问题、产品问题和技术问题， 对于我们的架构设计， 更关注的是技术问题。
举例来说，
购票的时候， 站在用户角度， 我提交订单了需要支付（用户问题）; 在经营者的视角来看， 我对用户提供的支付方式， 需要支持一切可以支付的第三方支付工具（业务问题）； 站在产品经理的角度上， 就需要体现出 支付需要逆向流程（退货）、异常流程、对账模块等（产品问题）； 站在架构代码的角度上来说， 我们需要考虑高并发、可用性、以及第三方支付链路的整合（技术问题）。
3、架构
在我们做架构的时候，还有个kiss原则（keep it simpe and smile）
simpe: 架构的就是要解决问题的 , 如何让我们的系统有可扩展性和可维护性；如何让我们的系统能够恰到好处地解决问题；如何让我们的系统能够运行3-5年不需要重构；
smile：保持微笑迎接各种否定； 业务部门的挑战（价值问题）、成本部门的挑战（ROI问题？？）、测试部门的挑战（可测试性）；技术部门的挑战（可行性与工期）
对于如何让我们的系统有可扩展性和可维护性， 老师引出了七大设计原则的讲解：这里就不自己敲了， 引用其他人已经总结好的内容。
转载七大设计原则： https://www.cnblogs.com/1287758807cjh/p/8286554.html

终上所述： 什么是架构呢？ 架构的目的是什么？
架构=模块结构+模块关系+约束+设计原则+演化方向！
架构的目的是解决问题！ 确定系统边界，在技术层面上决定做与不做； 确定系统里各模块之间的依赖关系与模块的宏观输入与输出；使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化明确非功能性需求（安全性、可用性、可扩展性等）
明白了目的， 我们还需要有相应的表达让其他人能够快速准确的理解我们的架构， 进行决策与实施。
由此， 我们需要进行架构图的编写。
业务架构图、应用架构图、数据架构图、技术架构图。
业务架构图：转载 业务架构图一（三步画出产品业务架构图）.
应用架构图：？？
数据架构： ？？
技术架构图： ？？
4、UML
静态结构图：类图、对象图、包图、组件图、部署图
动态行为图：交互图（时序与协作图）、状态图、活动图

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

特别说一下时序图： 时序图只关注正常流程， 通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

时间关系， 初稿就这样了， 后续再把理解透彻的地方重新改一下…
关键的地方是在需求分析和问题分析上学到了。