项目落地过程: 需求分析->可行性->设计->编码->测试->发布
kiss原则: keep it simple and smile(大道至简,迎接否定)
DRY: Don’t repeat yourself.
需求分析
- 用户诉求(调研)
- 背后逻辑(人性是需求的本源)
- 可行性结果分析
1.数据化结果判断合理性
2.正反案例说明需求需改进的地方
3.用户路径和触点推演合理性及危害性
非结构——结构
需求产品化: 模块化、 配置化、 有逻辑
架构
1.什么是架构?
组成+决策
组成:模块关系+模块结构
决策:约束+设计原则+演化方向
2.为什么架构?
解决问题
技术层面上确定模块结构,梳理各模块之间的依赖关系与模块的宏观输入与输出,使后续的子系统或模块设计在一个既定的技术约束上继续演化
1.可扩展和维护
2.使用合理的解决问题方式
3.尽量不重构
3.如何架构?
3.1架构分类
3.1.1业务架构
使用方法论,对涉及到的业务单元进行边界划分
3.1.2.应用架构
对系统进行垂直应用层次拆分
3.1.3.数据架构
对存储数据的逻辑,根据各个系统,不同时间段应用场景,数据读写分离,异构,缓存,分布式等策略进行划分。
分析:
数据源
存储方式
如何架构设计
3.1.4技术架构
根据需求,进行技术选型,并描述清楚之间的关系。
3.2 架构图
3.2.1 介绍
水平的业务单元+垂直技术单元 构成的逻辑结构图
3.2.2 作用
可视化 提高效率
3.2.3 常用
逻辑视图: 功能需求架构(逻辑结构图)
开发视图: 开发期质量属性的架构(UML图)
处理视图: 运行期质量属性的架构(UML图)
3.2.4 UML类图
常用:类图,时序图,流程图
静态结构图:类图、对象图、包图、组件图、部署图
动态行为图:交互图(时序图与协作图)、状态图、活动图
3.2.5 类之间的关系
泛化关系:继承
实现关系:实现接口
聚合关系:业务与整体 独立存在
组合关系:业务与整体 同生共死
依赖关系:只要在类中用到了对方,就存在依赖关系
关联关系:体现的是业务逻辑的关系,是依赖关系的特例
3.2.6 七大设计原则
单一职责: 不忘初心(高内聚,低耦合)
里氏替换: 父有子必有
接口隔离原则: 接口尽可能小(退款:用户侧,管理侧)
组合: 恋爱关系(尽可能使代码暴露与本类相关的代码,避免接口污染)
依赖倒置原则:细节依赖于抽象,底层依赖于高层
迪米特原则:互相了解的信息尽可能少,只关注输入和输出
开闭原则:对扩展开放(变化的点隔离出来)。
3.2.7 分层
**多视角:**用户/业务/产品/技术
3.2.8 如何画?
1.分析类型(业务,应用,数据,技术)
2.确定要素(产品,技术,服务)
3.关联(包含,并列)
4.输出关联关系
【注意】:布局,颜色,逻辑(突出重点!)