本系列文章通过逐章回答《Fundamentals of Software Architecture》（下文简称 FOSA）一书中的课后思考题，来深入理解书中的核心概念和理论，从而提升我们的软件架构设计能力。本篇为第一章内容。

本章的课后题是：

  1. What are the four dimensions that define software architecture? 软件架构定义的四个维度是什么？
  2. What is the difference between an architecture decision and a design principle? 架构决策和设计原则有什么区别？
  3. List the eight core expectations of a software architect. 软件架构师的核心期望有哪些？
  4. What is the First Law of Software Architecture? 软件架构的第一定律是什么？

1. 软件架构定义的四个维度

  • structure of the system: refres to the type of architecture style (or styles) the system is implemented in (such as microservices, layered, or microkernel).
  • architecture characteristics: define the success criteria of a system, which is generally orthogonal to the functionality of the system.
  • architecture decisions: define the rules for how a system should be constructed.
  • design principles: differ from architecture decisions in that a design principle is a guideline rather than a hard-and-fast rule.

FOSA 中强调，软件架构不单单是"架构"本身，因为它无法揭示系统为何如此构建（why is more important than how），所以书中用了 4 个维度来定义软件架构的方方面面。

1.1 系统结构

系统结构可能就是我们最常谈到的"架构"，指的的整个软件的架构风格（Architecture Style），例如微服务（Microservices）、分层架构（Layered）或微内核（Microkernel）。

书中后续篇章详细介绍了以下 8 种架构风格：

  1. 分层架构（Layered Architecture）
  2. 流水线架构（Pipeline Architecture）
  3. 微内核架构（Microkernel Architecture）
  4. 基于服务的架构（Service-Based Architecture）
  5. 事件驱动架构（Event-Driven Architecture）
  6. 基于空间的架构（Space-Based Architecture）
  7. 编排驱动的服务导向架构（Orchestration-Driven Service-Oriented Architecture）
  8. 微服务架构（Microservices Architecture）

FOSA 强调，只用结构来描述架构是不够的，因为它无法揭示系统为何如此构建。因此我们在设计之初，明确选择和识别现有系统的架构风格是基础，但必须超越这一层去理解其背后的驱动因素。

1.2 架构特性

架构特性就是一堆的 -ilities，书中偏爱"架构特性"这个描述，而非"非功能性需求"或"质量属性"，因为这二者带有负面或事后评估的含义，而架构特性，应当是在架构设计之初，就被纳入深入思考。

架构特性有 3 个标准：

  1. 指定非领域设计考虑：更关注"如何"实现需求和"为什么"做出某些选择，而不是应用程序"应该做什么"的功能需求。
  2. 影响设计的某种结构方面：架构特性要求在设计中进行特殊的结构考虑。
  3. 对应用程序成功其重要作用：每个架构特性都会带来架构的复杂度，所以要尽可能选择最少的、但对成功至关重要的架构特性予以实施。

架构特性可以分为 3 大类：

  1. 操作型架构特性
  2. 结构型架构特性
  3. 交叉切面架构特性
架构特性分类

将任意一个架构特性实现到极致的代价都是极大的，相应也会带来更复杂的架构设计，所以在项目早期，我们需要与领域专家和业务干系人紧密合作，识别和明确最重要的架构特性，用最少的努力，达到最大的产品效果。

1.3 架构决策

架构决策定义了系统如何构建的规则。它们构成了系统的约束，并指导开发团队哪些是被允许的，哪些是不允许的。比如在分层架构中，架构师可能会规定只有业务层额和服务层可以访问数据库，从而限制了表示层直接调用数据库。

架构决策应当被文档化，例如使用架构决策记录（Architecture Decision Records，ADRs），这有助于解释决策的背景、理由和后果，避免重复讨论。

架构决策记录 ADR

1.4 设计原则

设计原则是指导方针（Guideline）而非硬性规则（hard-and-fast rule），用于提供指引和建议，帮助开发团队在面对特定情景时做出最佳选择。

2. 架构决策和设计原则的区别

  • 架构决策：硬性规则
  • 设计原则：指导方针

3. 软件架构师的核心期望

3.1 八大期望

  1. Make Architecture Decisions

    架构师应定义指导团队技术决策的架构决策和设计原则。核心是"指导（guide）"而非"指定（specify"。

  2. Continually Analyze the Architecture

    架构师必须持续、全面地分析技术和问题域的变化，以确保架构的健壮性和业务相关性。

  3. Keep Current with Latest Trends

    架构师需要不断跟踪和保持对最新技术、框架、平台和环境的了解。

  4. Ensure Compliance with Decisions

    架构师需要持续验证开发团队是否遵循已定义、文档化和沟通的架构决策和设计原则。

  5. Diverse Exposure and Experience

    架构师应接触并体验多种多样的技术、框架、平台和环境，从而帮助架构师在面对新问题时，可以从更广阔的技术栈中选择最佳解决方案。

  6. Have Business Domain Knowledge

    优秀的软件架构师不仅理解技术，还理解问题空间的业务领域，从而设计出贴合业务发展的有效架构。

  7. Possess Interpersonal Skills

    成为一名有效架构师，人际交往能力至少占一半。架构师需要积极与团队协作、进行双向沟通，提供指导和辅导，避免成为象牙塔架构师（Ivory Tower Architecture）。

  8. Understand and Navigate Politics

    架构师需要理解企业内部的政治环境，并能驾驭其复杂性。在架构决策受到挑战时，沟通过程中需要始终提供技术和业务上的双重理由，学习将强硬要求转化为请求，并利用同理心和影响力而非头衔来推动决策。

3.2 成长指南

成长为一名合格的软件架构师是一个持续学习和实践的过程，涵盖技术、沟通和领导力等多个方面，这里笔者结合 FOSA 书中的 19~24 章内容进行梳理总结：

  • 持续学习和扩展技术广度
    • 20 分钟法则：每天至少投入 20 分钟学习新知识或深入研究特定主题，这里笔者推荐可以每天（或每周）跟 LLM 深入探讨一个技术话题或前沿技术概念。
    • 技术雷达：利用如 ThoughtWorks 技术雷达的方法来组织和评估新技术，识别值得投入时间深入研究的"试用"技术，并根据趋势更新知识库。
    • 社交媒体：积极利用社交媒体发现新趋势和技术，将其放入个人技术雷达的"评估"环中。
  • 实践权衡分析
    • 失败乃成功之母，实践是检验真理的唯一标准。只有在实践中不断的进行架构设计、权衡抉择、推翻重建，才能不断深化对理论知识、业务领域和现实世界的理解。
    • 培养批判性思维，避免过度设计和"黄金镀层"现象，专注于解决实际问题，而不是为了技术而技术。软件架构中没有错误的答案，只有昂贵的答案。
  • 培养沟通和协作能力
    • 通用语言：参考 DDD（领域驱动设计）思想，在所有项目相关沟通中（包括代码和文档）都使用通用语言，避免沟通歧义，减少沟通成本。
    • 4C 原则：在沟通中始终关注沟通（Communication）、协作（Collaboration）、清晰（Clarity）和简洁（Concisensess）这 4 个要素。
    • 主动倾听：认真倾听利益相关者的声音，理解他们的业务需求和痛点，并寻求澄清。
  • 通过榜样领导团队
    • 赢得尊重
    • 辅导和引导
    • 化请求为帮助
    • 使用清单
  • 深入业务领域
    • 分析业务领域和子域，识别公司的主要活动领域、竞争策略。
    • 学习领域驱动设计，始终让业务驱动软件设计决策，而不是为了应用最新的技术而技术。

4. 软件架构的第一定律

  1. Everything in software architecture is a trade-off.
  2. If an architecture thinks they have discovered something that isn't a trade-off, more likely they just haven't identified the trade-off yet.
  3. Why is more important than how.

软件架构中的一切都是权衡。一个解决方案是否是"最佳"的，取决于部署环境、业务驱动因素、公司文化、预算、时间限制、开发人员技能集以及其他数多种因素。架构师应追求"最不差架构（least worst architecture）"，而非"最佳架构"。试图支持过多的架构特性往往会导致过于通用且笨重的设计，使其难以成功。

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章

快来参与讨论吧~