软件架构指南：从定义到应用与企业架构的全面解析
导航链接
有指向 Refactoring、Agile、Architecture 等内容的链接，如 Refactoring、Agile 等。
主题分类
涵盖架构、重构、敏捷开发、交付、微服务、数据、测试、领域特定语言（DSL）等主题。
关于作者
包含关于作者的介绍链接，如 关于、书籍、常见问题解答。
内容板块
有视频、内容索引、片段、桌游、摄影等内容。
Thoughtworks 相关
提供 Thoughtworks 的主页、洞察、职业发展、技术雷达、工程技术等链接，如 主页、洞察 等。
关注渠道
可通过 RSS、Mastodon、领英、Bluesky、X、桌游极客（BGG）关注，如 RSS、Mastodon 等。
软件架构指南概述
在软件行业，“架构”是对软件系统内部设计最重要方面的模糊定义，良好的架构很重要，否则添加新功能会变慢且成本增加。作者长期对“架构”术语持谨慎态度，通过强调良好架构应支持自身演进且与编程紧密交织来消除担忧。本页面概述作者对软件架构的看法并指向更多资料。
什么是架构
软件界长期争论架构的定义，有人认为架构是系统基本组织方式或最高层组件连接方式，作者受与 Ralph Johnson 邮件交流影响，Ralph 质疑这种表述，认为架构更好的定义是专家开发者对系统设计的共同理解。另一种常见定义是架构是“项目早期需要做出的设计决策”，Ralph 认为这更像是希望在项目早期做对的决策，他的结论是“架构关乎重要的事情，无论那是什么”。Ralph 的邮件构成作者为 IEEE 软件撰写专栏的核心内容，探讨软件架构含义和架构师角色。
为什么架构很重要
对于软件产品客户和用户，架构难以立即感知，但糟糕的架构是产生冗余代码的主要原因，含大量冗余代码的软件更难修改，导致功能交付变慢、缺陷增多。高内部质量能更快交付新功能，虽然短期内牺牲质量可行，但人们常低估冗余代码使交付变慢的速度，有经验的开发者认为关注内部质量数周内可见成效。2015 年在 OSCON 大会上，作者做了探讨架构定义和重要性的演讲。
应用架构
应用边界
软件开发中确定软件边界是未解决的问题，许多面向服务架构支持者认为应用会消失，但作者认为应用不会消失，因为应用边界难界定，本质上应用是社会建构。
微服务指南
微服务架构模式是将单个应用开发为一组小型服务的方法，各服务在自己进程中运行，通过轻量级机制通信，围绕业务能力构建，可独立部署，能用不同编程语言和数据存储技术。微服务虽流行但带来分布式增加、一致性减弱的成本，且需成熟运维管理。
遗留系统替换模式
组织替换现有软件系统常陷入未完成循环，总结出一系列模式帮助打破循环，包括明确预期结果、分解替换工作、逐步交付和改变组织文化。
微前端
前端开发不易，多个团队在大型复杂产品上开发前端难度更大。介绍将前端单体应用拆分为更小、更易管理部分的新趋势，讨论优缺点、实现方案并展示示例应用。
图形用户界面（GUI）架构
图形用户界面为用户和软件系统提供丰富交互，管理复杂，需精心设计架构控制。表单和控件模式适用于简单系统，复杂时多数人转向“模型 - 视图 - 控制器”（MVC），但 MVC 易被误解，使用该名称的系统有差异，理解 MVC 可将其视为一组原则。
无服务器架构
无服务器架构整合第三方“后端即服务”（BaaS）服务和/或在“函数即服务”（FaaS）平台托管临时容器中运行自定义代码，减少对传统持续运行服务器组件的需求，可降低运营成本、复杂性和工程前置时间，但增加对供应商依赖且支持服务不成熟。
表示层 - 领域层 - 数据层分层
模块化信息丰富的程序常见方法是分为表示层（UI）、领域逻辑层（业务逻辑）和数据访问层，如 Web 应用分为 Web 层、业务逻辑层和数据访问层。
分布式系统模式目录
分布式系统编程面临特殊挑战，许多组织依赖核心分布式软件，2020 年 Unmesh Joshi 收集解决方案作为模式并发布，2023 年以《分布式系统模式》出版，页面链接模式摘要和 O'Reilly 在线电子书相关章节。
特性开关（又名特性标志）
特性开关是强大技术，允许团队不更改代码修改系统行为，分不同使用类别，实现和管理开关时要考虑分类，开关会引入复杂性，可通过实践和工具管理配置并限制数量。
使用成熟的 UI 模式模块化 React 应用
成熟的 UI 模式在前端开发未充分利用，本文探讨将其应用于 React 开发，通过重构代码示例展示好处，强调分层架构对组织 React 应用的作用。
企业架构
应用架构关注概念性应用边界内架构，企业架构着眼于大型企业整体架构，组织规模大需协调多个独立开发的代码库。企业架构工作是理解中央协调方面和形式，极端的中央架构团队和完全不协调都有问题，作者倾向去中心化，但要避免问题。
企业架构师加入团队
企业架构团队常与日常开发脱节，Rebecca 认为企业架构师加入开发团队更有成效。
创建集成的业务和技术战略
为有效利用技术，需将技术思维与业务计划结合，开发概念框架帮助战略思考，确定十一个战略方向，列出关键业务问题和调查内容，框架可制定有效技术战略并开发新收入来源。
产品模式优于项目模式
软件项目是常见开发方式，产品模式使用持久团队解决业务问题，能快速调整方向、缩短周期时间、验证收益并保持架构完整性。
架构师电梯 —— 探访高层
大型组织中 IT 部门与高管层相隔远，业务和数字战略与执行脱节，架构师角色是在高层和底层间穿梭支持数字工作。
精益企业中企业架构师的角色
组织采用敏捷思维时，企业架构师角色变化，不再直接做选择，而是帮助他人选择、传播信息，形成愿景、搭建桥梁、建立学习社区。
使用 REST 进行企业集成
大多数内部 REST API 是一次性 API，本文讨论非公开 API 约束和灵活性及大规模 RESTful 集成经验教训。
主题分类（重复）
涵盖架构、重构、敏捷开发、交付、微服务、数据、测试、领域特定语言（DSL）等主题。
关于作者（重复）
包含关于作者的介绍链接，如 关于、书籍、常见问题解答。
内容板块（重复）
有视频、内容索引、片段、桌游、摄影等内容。
Thoughtworks 相关（重复）
提供 Thoughtworks 的主页、洞察、职业发展、技术雷达、工程技术等链接，如 主页、洞察 等。
关注渠道（重复）
可通过 RSS、Mastodon、领英、Bluesky、X、桌游极客（BGG）关注，如 RSS、Mastodon 等。