ytrkkaa

摘要： 课程进行到最后阶段，最大的变化是——不再只是听课和看书，而是要把学到的知识用在一个真实的项目上。我们小组的课程设计题目是开发一个具备一定复杂度的Web应用，要求在设计阶段明确架构选型和质量属性战术。 设计过程中的体会 架构选型不是“选最流行的” 我们选用了分层架构（表示层-业务层-数据访问层）。理由 阅读全文

摘要： 课程进行到现在，我越来越意识到一个之前被忽略的问题：好的架构设计如果无法清晰地表达出来，就没有价值。 架构师不仅要设计系统，还要让团队成员、客户、管理者理解这个设计。这就是架构描述的重要性。 4+1视图模型 课程重点讲了Kruchten的4+1视图模型，它从五个角度描述一个系统的架构： 逻辑视图（L 阅读全文

摘要： 质量属性我一直知道很重要——性能、可用性、可修改性这些概念谁都懂。但问题是：怎么把它们落实到设计里？ 课程讲到“战术”这个概念时，我才有了具体抓手。 可用性战术 可用性的核心是“系统出故障时能维持服务”。课程中讲到的战术包括： 错误检测：如心跳机制、Ping/Echo，用来及时发现故障 错误恢复：如 阅读全文

摘要： 刚开始学架构风格时，我觉得这有点像“背概念”——记住每种风格的特点、优缺点、适用场景，考试能答上就行。但随着课程的推进，我发现这其实是设计的工具箱。就像建筑师要知道哥特式、巴洛克式、现代主义分别适合什么建筑一样，软件架构师也必须对各种风格了然于胸，才能在面对具体问题时快速找到合适的方案。 几种关键风 阅读全文

摘要： 目前对以下几个核心概念建立了基本理解： 架构风格：分层、C2、管道-过滤器、事件驱动、仓库、MVC等经典风格的特点及适用场景 质量属性：可用性、可修改性、性能、安全性、可测试性的含义和重要性 质量属性场景：用“刺激-环境-响应-度量”来描述一个具体的质量属性需求 体系结构描述：UML、4+1视图、A 阅读全文

摘要： 这是一个容易被忽略但极其重要的问题。很多人默认“架构是为开发人员服务的”——让代码更好写、更好改。但这只是冰山一角。 架构首先解决的是“老板”或“出资方”的问题。 他们的核心诉求是：在可控的成本和时间内，把一件事情做成，并且能持续获利。架构通过合理的分工和规划，把一个大项目变成可并行推进、可独立交付 阅读全文

摘要： 远古时期，一个人就能完成狩猎、采集、生火等生存活动，没有“架构”这回事。但随着人类社会的复杂化，事情开始超出个体能力边界：修建一座金字塔、组织一场战役、管理一个国家的税收，这些都远非一人之力可为。于是分工诞生了，架构也随之诞生。 具体来说，架构的出现有三个驱动力： 第一，规模超过了单人的认知负荷。 阅读全文

摘要： 在读完前四章后，我对“架构”的理解经历了一次彻底的刷新。架构不是UML图，不是技术选型，不是分层方案——这些只是架构的“产物”和“表达”，而非架构本身。 王概凯给出了一个极具穿透力的定义：架构，是对系统中利益相关者的权责进行合理切分，并通过有效的沟通机制让这些切分后的部分能够协同工作，以完成单个人无 阅读全文

摘要： 核心观点：应对变化的核心战术是“防止连锁反应”。 软件唯一不变的是变化。可修改性不是让代码“好改”就行，而是要有系统性的战术来保障。其中最关键的是防止连锁反应。 关键洞察： 战术类型 具体方法 解决什么问题 信息隐藏 封装内部实现，只暴露接口 修改内部逻辑时不波及调用方 维持已有接口 新增接口而非修 阅读全文

摘要： 核心观点：切分的核心是“高内聚、低耦合”，但前提是“权责对等”。 很多架构图看起来很美，层层分明、环环相扣，但落地时完全走样。原因往往是切分时只考虑了技术维度，忽略了人的维度。 关键洞察： 模块边界的划分标准：每个模块应该是一个“可以独立决策、独立交付、独立演进”的业务能力单元。技术分层（Contr 阅读全文