默认分类
未读
Day28-47｜7.4.2 软件架构复用的原因
Day28-47｜7.4.2 软件架构复用的原因 一、为什么架构复用值得单独学习 系统架构设计面对的是有限时间、有限预算和不断变化的需求。每个项目都从零开始，会重复支付需求分析、技术选型、风险识别、接口设计、部署验证和运维建设的成本。架构复用的根本原因，是把组织过去已经付出的学习成本转化为未来项目的
默认分类
未读
Day28-48｜7.4.3 软件架构复用的对象及形式
Day28-48｜7.4.3 软件架构复用的对象及形式 一、复用对象的全景 软件架构复用的对象可以从抽象到具体排列为：原则、需求知识、分析模型、设计决策、架构风格、参考架构、框架与中间件、构件、接口契约、数据模型、测试资产、部署资产和运维知识。不同对象的稳定性、复用成本和风险不同，不能用同一种方式管
默认分类
未读
Day28-49｜7.4.4 软件架构复用的基本过程
Day28-49｜7.4.4 软件架构复用的基本过程 一、过程总览 软件架构复用不是一次性的技术选型，而是一个闭环过程：明确复用目标，检索和识别候选资产，评估适用性，选择复用形式，完成适配与集成，验证质量属性，发布为项目基线，并在运行中反馈和维护资产。考试案例常要求补充过程步骤，建议使用这条主线作答
默认分类
未读
Day29-01｜7.5.1 DSSA 的定义：面向特定领域的软件体系结构
Day29-01｜7.5.1 DSSA 的定义：面向特定领域的软件体系结构 一、教材定位 DSSA 是 Domain-Specific Software Architecture 的缩写，中文通常译为“特定领域软件体系结构”。它是第7章“软件架构复用”的重要落点，也是高级系统架构设计师考试中连接架构
默认分类
未读
Day29-02｜7.5.2 DSSA 的基本活动：从领域分析到应用实例化
Day29-02｜7.5.2 DSSA 的基本活动：从领域分析到应用实例化 一、教材定位 上一节学习了 DSSA 的定义，本节进一步回答：一套 DSSA 是怎样建立起来的？它不是先画一张漂亮的架构图，再要求所有项目照着实现，而是通过一组连续活动，把领域知识转化为领域模型、参考需求、参考架构和可复用资
默认分类
未读
Day29-03｜7.5.3 参与 DSSA 的人员：让领域知识、架构决策与复用工程形成合力
Day29-03｜7.5.3 参与 DSSA 的人员：让领域知识、架构决策与复用工程形成合力 一、教材定位 DSSA 不是架构师一个人的工作。它同时涉及业务领域知识、软件架构设计、产品线规划、构件开发、测试验证、项目交付和资产治理。参与人员的职责边界如果不清晰，最容易出现两种问题：一是平台团队按照自
默认分类
未读
Day29-04｜7.5.4 DSSA 的建立过程：从领域范围到可复用资产
Day29-04｜7.5.4 DSSA 的建立过程：从领域范围到可复用资产 一、教材定位 DSSA 的建立过程是第7章软件架构复用内容的收束。前面学习了 DSSA 的定义、基本活动和参与人员，本节将它们组织成一套可执行的方法。DSSA 建设不是单个项目的临时设计，而是围绕一个领域持续开展的工程：选择
默认分类
未读
Day29-05｜8.1.1 质量属性概念：从“系统能做什么”到“系统做得怎么样”
Day29-05｜8.1.1 质量属性概念：从“系统能做什么”到“系统做得怎么样” 一、教材定位 系统质量属性与架构评估是高级系统架构设计师综合知识、案例分析和论文写作的共同基础。功能需求回答系统要完成哪些业务活动，质量属性回答系统在什么约束下、以什么水平完成这些活动。一个系统即使功能完整，如果响应
默认分类
未读
Day29-06｜8.1.2 面向架构评估的质量属性：把抽象目标转化为架构证据
Day29-06｜8.1.2 面向架构评估的质量属性：把抽象目标转化为架构证据 一、教材定位 上一节介绍了质量属性的概念，本节进一步说明哪些质量属性需要在架构层面重点关注，以及如何把它们用于架构评估。架构评估不是检查架构图是否美观，而是判断架构设计是否能够满足重要质量目标，并识别不同方案的风险、权衡
默认分类
未读
Day29-07｜8.1.3 质量属性场景描述：让架构目标可讨论、可设计、可验证
Day29-07｜8.1.3 质量属性场景描述：让架构目标可讨论、可设计、可验证 一、教材定位 质量属性场景描述是系统质量属性与架构评估之间的桥梁。性能、可靠性、安全性、可修改性等质量目标如果只停留在“高性能”“高可靠”“安全可控”等形容词层面，就无法指导架构决策，也无法形成测试标准。质量属性场景把
默认分类
未读
Day29-08｜8.2.1 系统架构评估中的重要概念：从架构判断到风险与权衡
Day29-08｜8.2.1 系统架构评估中的重要概念：从架构判断到风险与权衡 一、教材定位 系统架构评估不是对代码进行一般性检查，而是在系统实现或重大变更之前，依据业务目标、质量属性和架构决策，判断架构方案是否可行、是否满足关键约束、是否存在高风险以及是否需要调整。架构评估中的概念很多，容易混淆：
默认分类
未读
Day29-09｜8.2.2 系统架构评估方法：用结构化过程发现架构风险
Day29-09｜8.2.2 系统架构评估方法：用结构化过程发现架构风险 一、教材定位 系统架构评估方法用于判断架构是否满足业务目标和质量属性要求。它不是一次简单的专家打分，也不是只在项目结束时做的验收，而是一组有输入、有步骤、有参与者、有证据和有输出的工程活动。高级系统架构设计师需要掌握评估方法的
