A -- 架构设计
2016-10-18 11:03:43 0 举报架构设计是软件开发过程中的关键环节，它涉及到系统的整体结构、组件、模块以及它们之间的关系和交互。一个优秀的架构设计能够提高系统的可扩展性、可维护性和性能，降低系统的复杂性和风险。在架构设计过程中，需要考虑多种因素，如业务需求、技术选型、团队协作等。通常，架构设计师需要具备丰富的编程经验、系统设计和项目管理知识，以便能够从整体上把握系统的需求和发展方向。
作者其他创作
大纲/内容
对内：修改相关联放到一起
模块
一定要从不同视角看问题运营，内部变更，外部依赖
复用-发布等价原则R-REP
组织目标模块目标
文章/章节
确定组件目的：职责边界明确，应该只有一个，金字塔结构组织研发速度很重要，快速成型，快速试用，快速试错，快速迭代，走到正确的方向CRP， CCP > R-REP内部先稳了，再考虑对外服务
模块L1-1
Open
硬币效应（利弊）：协作与制衡如何协作？如何制衡？
接口op3
房间可居住，基本单元
代码级别
编程范式
设计
顶层业务逻辑
DIP：???
为维度而组合
DIP控制流，依赖流依赖流反转，即与控制流反向
组件可独立部署，jar包，dll库完成一个边界的事情，独立王国，自治
SDP稳定依赖原则
名词，名字，没那么重要，背后的结构，来源，意义，比较重要
编程元素
模块(Close)
词（字），符号
建筑物
ISP（接口隔离原则）S 用接口I隔离变化不依赖没用的东西
考虑一个矛盾：研发速度 vs 复用
OCP中的C
面向对象（层次）
复用困难
模块一个中心思想，基于多个视角论证（归纳，演绎）
句子
什么是架构：what
组件成熟，目的明确，边界清晰，变化减少，主要是性能增强，纵向提升R-REP第一重要
接口op1
设计原则（SOLID），如何应对变化，组织代码，
共同闭包原则CCP
SOLID原则
ISP
系统
OCPOpen：对扩展开放（底层，依赖抽象-具体，机制）Close：对修改封闭（高层，规则）加功能（Open），不改变原代码（Close）
组件研发生命周期
OCP：层级划分
解决问题的方式
为避免不必要的发布而切分
组件目的，只有一个，最小边界，最小依赖
模块L2-1
使用方法，场景
共同复用原则CRP
横向，一个点拆分为多个模块
笔画
确定组件/模块的边界
。。。
变更影响太多组件
太多不必要发布
为复用而组合
随着时间，组件进行演进，需求的增加，导致边界不停的被突破和调整，但是，要始终把握最小边界，干净利落，坚决不依赖无用组件CRP
研发速度和组件成熟度
LSP
LSP：标准化（还没有完全想好）
上下层，抽象和具体，一个核心模块的N个功能点依赖一个模块实现了N个功能点基础组件实现了多个点，是经常变化的接口隔离一下
函数式（稳定，变化）
分层模型：核心架构不变（顶层稳定：抽象）底层可扩展可调整（底层变化：具体）
砖块
OCP
墙体
书
ISP：隔离变化（只关注它需要的）通过接口对变化做一层隔离只给别人需要的，不要多给
结构化（过程）
抽象，分层，分治，演化
SAP稳定抽象原则
分治：功能降解拆分(拆，合）
业务系统=功能A，功能B，功能C，。。。
功能性降解拆分
确定组件/模块的关系
类文件一个视角，一个方面的表达只有一个中心思想
时间
函数，数据如何用词，如何简洁表述清楚一句话
段落
对外：外部对其产生依赖原子化交易（供方发布，需方复用）
粘合性原则，使变大
SRP（康威定律的推论）组织，变更方，等等划分一组相关行为
SRP：确定边界（单一职责/一类职责），横向切分只有一个目标
组件特性3点，思考的点
A不想被B的修改影响，让B依赖A，A为核心（上层），B次之（下层）
排除性原则，使变小
ADP无环依赖原则
架构
接口op2
职业：暂无
0 条评论
下一页
