孤尽31天之架构与设计

T31项目简介

1.1项目简介

       类似12306售票网站，主要模拟售票流程和商品支付主流程。

项目基本涉及了大部分系统包括的基本功能模块和部分主流的模块，基本模块比如：登陆、用户管理，大部分系统都必须包括的基本模块；主流模块比如：车票订单和支付流程是当前大部分互联网系统必备的主流模块，具有典型的代表。

二、需求分析

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

2.2需求分析过程：在进行需求分析时需要注意的三个点包括需求边界、用户故事、用户路径。

需求边界：主要是确定哪些是已有的哪些是需要新开发的。

用户故事：每个需求的提出一般情况下都有一个需求的用户使用的实际场景故事，通过对用户故事的分析可以站在用户视角理解为什么这样做。

用户路径：操作人员与系统的任何接触和互动都可能是用户路径，用户路径应该尽可能的短，降低用户的使用成本，使用成本越低软件成功可能越高越容易被用户接受。

分析背后的人性：人性是提出需求的本源，是人身处在当前业务场景下的作为人独有的思想或行为方式或者习惯或爱好等。

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

2.3需求落地路径：需求分析-可行性研究-

需求进行分类：包括伪需求、权利需求、业务需求

伪需求：没有调研、没有目标、没有逻辑的需求

应对的措施有：

1. 用数据化的结果否定需求合理性；市场产品契合度PMF: Product Market Fit
2. 用正反案例说明需求需要改进的地方
3. 用户路径和触点的推演需求的合理性

权利需求：老板或者强势业务方的需求

应对措施：

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

2.给出更好的需求替代方案

3.从需求和案例角度说明需求快速上线危害性

2.4如何解决需求的冲突？

当多个用户的需求有冲突时如何解决？

首先需要进行对来源用户的重要程度进行划分，更重要的用户需要优先响应，至于如何响应则需要根据用户需求的合理性进行不同区分。

用户需求:需要对用户进行需求调用，通过调研得出用户的分层。

还需要考虑需求实现的成本：时间成本，人力成本，经济成本，情绪成本

2.2问题的分类

问题分为4类包括：本源问题（用户问题）、经营视角（业务问题）、体系结构（产品问题）、架构代码（技术问题）

例如用户问题：我想支付

业务问题：支持一切可以支付的第三方支付工具

KISS原则：keep it simpe and smile

架构的理念是大道至简单

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

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

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

重构往往是不可避免，但是

挑战

业务部门的挑战

成本部门的挑战

测试部门的挑战

技术部门的挑战

DRY 原则 一切重复的代码均可以抽象

Don’t Repeat

三、设计原则

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

七大设计原则的好处：能适应软件的未来演进变化和可能的需求变化，保持好的可维护性，并且在尽可能提高可读性和简单、以及稳定性减少人为造成系统错误发生的优点。

实践点：包括类图设计、接口设计

3.1单一职责

       最简单的，但却是最难的，高内聚、低耦合的延伸。属性和行为向着模块预先定义的功能内聚。为了更好的维护和扩展模块业务需要将固定的各个对象或功能聚合为一个完整的业务功能，该职责内的所有对象生命周期保持一致并在将来可能的演进时也不会被分离。

其中模块的名字非常重要：因为名字表达模块的核心功能，这样便于所以相关人员可以快速熟悉模块应该包括的功能和区分各个模块，也便于系统维护和功能演进。

3.2里氏代换原则

 父类能适用的地方子类必须也能使用，但是子类出现的地方父类不一定能出现。父类与子类的关系是一般与特殊的关系，并且子类与父类的基本的本质属性必须一致，这样才能保证能替换。

3.3接口隔离原则

接口的颗粒度要尽可能的小，接口里的方法强内聚于同一特征，这样的内聚必须根据实际的业务本质进行划分。

3.4组合复用关系

组合是一种松散关系，组合构成的对象方法暴露的少，组合的目的是避免接口污染。

一旦服务暴露，

3.5依赖倒置

主要包括：具体的体现是细节依赖抽象、底层依赖于高层，这样的好处是将公共服务进行抽象更好的进行公用，但是具体的实现参考抽象

3.6迪米特原则

       互相了解的信息少，使用一个接口只需要关注输入和输出，不需要关注该接口的内部实现。这样使得调用方只需要关注该接口约定的内容即可不会分散调用者的更多尽力。

3.7开闭原则

内容是：对扩展开发，对修改关闭，该原则是单一职责原则之外最难的。

扩展能力主要是对需求继续变化的适应能力，需要识别和隔离变化点这也是架构师的挑战之一，将变化隔离

商增定律

：商：

对抗的方式是商减：形式是开放性，开放性是系统能够有序接纳系统接纳外部能量的能力。在软件领域外部能量是：需求的多变、和业务的不断试错。扩展性设计是一种开闭原则的思维。

四、架构与架构图

什么是架构？架构是一种能力，而不是一个职位。

架构=组成+决策

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

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

决策是约束设计原则和演化方向

4.2架构的目的

1.确定系统边界，在技术层面上确定做与不做，

2.确定各个模块的依赖和模块的输入输出。

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

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

4.3架构图

定义：水平方向上的业务模块加上垂直方向的技术单元组成的逻辑结构图。

4.3.1如何画架构图

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

架构大致可以分为4类：业务架构、应用架构、数据架构和技术架构。

1. 业务架构：使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分。所以熟悉业务是关键。

主要解决：对业务按照一套方法论进行划分；2.对每个模块设定对应的业务功能

1. 应用架构：它是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。

主要解决：1.对系统进行整体层次划分；2.指定每个层次的服务，以及每个服务使用的工具、协议等

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

        解决问题：技术架构解决的问题包括：纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。

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

解决问题：主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计

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

       3.梳理关键要素之间关联（包含、支撑、同级并列）

4.3.2架构图的好坏标准：

       1.布局上：图形的上下左右前后6个方向的位置关系。

依赖以下原则：上边的内容依赖下面的模块，并且越往上越接近用户层面。

从左开始到右边是同级关系

       2.颜色：视觉中心在哪里，哪些元素被忽略，相关的技术其实忽略使用不明亮的颜色，用户操作以及主要

       3.逻辑：组件直接的依赖、业务实现的可行性、

4.3.3传统架构图分类：

       主要包括4类

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

        物理视图用于描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。

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

逻辑视图用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。

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

        开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。

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

        处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示。

1. 场景视图：场景视图用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示

活动图有泳道，流程图没有泳道，这是区别。

用例图：从用户视角出发。

五、Unified Model Language

Unified：说明以前不统一

Model：建模往往需要抽象

Language：交流，使用大家都认可的共同的协议和定义。

UML分类：

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

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

类的6大关系

泛化关系：继承关系

实现关系：实现接口

聚合关系菱形（）：业务上整体与部分可以分开，是关联关系，生命周期是可以不一样的。

组合关系菱形（黑色）：业务上整体与部分是不可分开，

判定逻辑1：生命周期完全一致，

还有一个逻辑2：脱离对方时本身是否还有存在价值，为什么一定要在架构上区分组合和聚合关系？分解任务：尽可能把组合分派同一个人或者同一个组，因为组合的交互密切要远高于聚合（因为是不可分开）

依赖关系：只要在类中用到了对方，就存在依赖关系，还可以区分有向，谁依赖谁

关联关系：体现的是业务逻辑的关系，是依赖关系的特例，还可以区分有向，谁关联谁。

类图实例：

是显示模型的静态结构，类图里也可以画接口和实现，车和人是聚合关系，

时序图：

通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，随着时间的演进对象之间的调用协作。

关注正常流程

不关注逆向流程

不关注异常流程

不关注分支判断