关于本书的赞誉

“术语耦合经常被人提及，却鲜有人真正理解。本书作者引领我们从‘始终解耦组件’这类简单的口号，进入复杂性和软件演进背景，深入探讨耦合的核心含义。若要从事现代软件开发，本书是必读之作！” 

Gregor Hohpe

——The Software Architect Elevator的作者

“是时候揭示耦合的多维本质，揭开其神秘面纱了。对于希望评估和理解设计决策实际影响的人士而言，本书极具参考价值。”

Chris Bradford

——剑桥咨询公司的数字服务总监

“耦合与软件一样古老，是很难把控和解释的概念。本书作者却轻松驾驭，阐述了耦合的方方面面，提出衡量和平衡现代分布式系统中耦合的具体模型。本书是每位软件从业者的必读佳作！”

Laila Bougria

——解决方案架构师兼工程师

“软件架构师和开发者的必备书目，本书对耦合概念进行了独到、极具实践价值的探讨。本书将成为未来行业交流以及发表作品时被反复引用的关键资料。” 

Michael Plöd

——INNOQ研究员

“每个软件工程师都对耦合十分敏感，耦合是连接各部分的纽带。然而，很多时候，他们对于耦合本质的理解仍然模糊不清。本书作者介绍了必备的智能工具，从全新视角系统地探讨了耦合这一核心议题。” 

Ilio Catallo

——高级软件工程师

“耦合是软件开发中最难以捉摸的主题之一。然而作者通过本书帮助读者充分理解耦合的概念，并将它变成设计工具。本书是每一位从事软件设计(尤其是复杂软件设计)的人士不可或缺的指南。” 

William Santos

——软件架构师

“本书是所有软件架构师的必读书目。作者巧妙地揭开了耦合的神秘面纱，提供了有效平衡耦合的实用见解和策略。本书对于构建模块化、可扩展且易于维护的软件系统来说具有不可估量的价值，强烈推荐！” 

Vadim Solovey

——DoiT International的首席执行官

“本书是致力于打造高质量、可演进系统的架构师的必读之作。作者精准地对依赖关系进行了专业分类，揭示了不同的设计如何根据组件距离和更改频率影响工作量，并引入了统一的耦合度量指标。作者还深入浅出地开展案例研究，通过阐明和纠正失衡现象，引导读者实现最佳模块化和长期系统适应性。”

Asher Sterkin

——独立软件技术专家

“这本开山之作将软件设计的关键要素统一到一个级联模型中，以评估软件系统的耦合。其见解为架构师提供了一个宝贵的框架，可用于设计跨越遗留和现代架构的模块化、演进式系统。”

Felipe Henrique Gross Windmoller

——巴西银行的软件工程师

“本书系统地凝练超过半个世纪的软件设计知识，全面阐述了耦合的概念、维度及其有效管理办法。若软件设计是一场与复杂性相抗衡的持久战，那么本书就是这场战争制胜的法宝。”

Ivan Zakervsky

——IT架构师

丛书主编序

我想起10年前，在一两次会议上见过Vlad。我对他印象非常深刻，他是一个沉静寡言、思维缜密、幽默风趣的人。但他并没有过分地沉默寡言，他在会议上发表的饱含深刻见解的演讲就证明了这一点。从那时起，我们就时不时见面。我们最近一次见面是在新冠疫情封控政策实施前的纽约软件架构会议上。尽管新冠疫情封控确实令人不快，但正是在这一关键时期，我出版系列丛书的意向得到批准。此后不久，我邀请Vlad为系列丛书写一本关于平衡软件耦合设计的书。令我欣慰的是，他同意了。在接下来的几年里，Vlad遇到了许多挑战，有家庭琐事，也有如何在令人抓狂的新冠疫情时期处理好生活与工作。然而，他始终坚持工作。我曾多次审阅本书，见证了它从初稿到成书的蜕变过程。不得不承认，以一种全新而有力的方式将过去的实践融入本书，这种体验令我着迷。在介绍完本系列丛书的主旨后，我将进一步对本书展开说明。

系列丛书旨在引导读者提升软件开发的成熟度，并在以业务为导向的实践中取得更大的成功。该系列丛书强调使用各种方法进行有机改进，主要包括响应式架构与编程、面向对象架构与编程、函数式架构与编程、领域建模、适度规模的服务、设计模式以及API。此外，该系列丛书将介绍相关基础技术的最佳应用实践。

目前，我只关注新词语：有机改进(organic refinement)。

“有机”(organic)这个词最近引起了我的注意。当时一位朋友兼同事用它描述软件架构，这让我眼前一亮。虽然我曾听过并使用过“有机”这个词来描述软件开发，但直到那次我亲耳听到“有机架构”这种说法时，才真正认真地思考它的含义。

想想有机，甚至有机体[ 译者著：organtic在本书中译为“有机”，organism在本书中译为“有机体/生命体”，organization在本书中译为“组织”。]这个词，在大多数情况下，这些术语指代生命体，但也用于描述具有某些类似生命形态特征的无生命体。“organic”一词起源于希腊语，原指人体的功能性器官。若追溯“organ”一词的词源，会发现它原本的用法更加广泛：既可以表示身体的器官，也可以指实现或执行某事，还能用来描述一种用于制作或完成任务的工具，甚至还能表示一种乐器。而实际上，“organic”一词正是延续了这条语义脉络。

我们很容易联想到各种有机体，即从庞然大物到微观单细胞形式的生命体。然而，当用有机体描述具有某些类似生命形态特征的无生命体，脑海中可能不会那么轻易地浮现相关示例。其中一个示例是组织，从词汇学角度看，组织(organization)一词含有机(organic)和有机体(organism)这两个词的前缀。在这种意义上的有机体是指一种具有双向依赖关系的结构。一个组织之所以是有机体，是因为它由各个部分组合起来。这种有机体离不开各个部分，而各个部分也离不开它。

从这个角度看，我们可以将这种思维应用于非生命体上，因为它表现出类似于生命体的特征。以原子为例，每个原子本身都是一个独立的系统，而所有生命体都是由原子组成的。然而，原子不会繁殖。即便如此，我们还是不难从某种意义上将原子视为生命体，因为它们在永无止境地运动。原子甚至会与其他原子结合。当这种情况发生时，每个原子不仅本身是一个独立系统，还会与其他原子一同成为子系统，共同合作形成一个更大的整体系统。

因此，有关软件的各种概念都具有某种有机的特性，因为即便是非生命体，也带有生命体的某些特性。当我们通过具体场景讨论软件模型概念，或绘制架构图，或编写单元测试及其对应的领域模型单元时，软件便开始“活”了起来。它并非一成不变，因为我们会不断地讨论如何改进它。在此过程中，一个场景会引发另一个场景，从而对架构和领域模型产生影响。随着其不断迭代，改进所带来的价值会不断累积，这将促使有机体逐步成长。随着时间的推移，软件也在不断改进。我们通过有效抽象来处理和解决复杂问题，而软件也在不断地发展和更改形态，这一切都是为了更好地为全世界范围内的真正的生命体提供更有效的服务。

遗憾的是，软件有机体的发展往往不尽如人意。即使它们一开始健康状况良好，也往往会生病、畸形、长出异常部位，出现萎缩和退化。更糟的是，出现这些症状皆因改进失败，最终事与愿违。最糟的是，每一次改进失败，并不会让这些复杂而病态的系统彻底崩溃死亡。哎，要是它们能自行消亡就好了！但实际上，我们不得不“杀死”它们，而杀死它们需要具有屠龙勇士般的胆识、技巧和毅力，并且，不只需要一个，而是几十个身强力壮的屠龙勇士。事实上，这几十个屠龙勇士还得拥有超凡的智慧。

这就是该系列丛书的作用所在。其旨在帮助你通过多种方法变得更加成熟并取得更大的成功，内容主要包括响应式架构与编程、面向对象架构与编程、函数式架构与编程、领域建模、适当规模的服务、设计模式以及API。此外，该系列丛书将介绍相关的基础技术的最佳应用实践。这不是一蹴而就的。它需要有目标、有技巧地有机改进。我和各位作者愿鼎力帮助你。为此，我们已竭尽所能以实现这一目标。

平衡软件之间的耦合是否可以像有机生命体一样？当然是！试想从一个代码“黑洞”式仓库开始，所有混乱的代码就像污泥般汇聚此处。这简直糟糕透顶！如何才能从这样的泥沼中长出鲜活的新生命呢？其实很简单，可以先挖掘和分离这些混乱代码，添加一些优质代码“土壤”和“养分”，再围绕这些肥沃土壤构建一些模块化容器，然后在每个容器里播下种子——有常见的、有特别的，甚至还有一些“异域风情”的作物。很快，你会发现，新生命诞生了！

嗯，差不多是这样，但也不完全是。你必须了解“软件园艺”这门学问，包括汲取耦合的基础知识，比如耦合的定义，耦合的优缺点，耦合与系统设计和复杂性的关系，当然也包括模块化如何提供帮助。奠定坚实的基础后，你还要掌握一整套维度，帮助你评估软件环境是否支持可持续生长，即强度、空间和时间是否合适。接下来还会介绍模块耦合和类型共生性的概念，这便需要引出Vladik提出的新模型：集成强度。这些概念可能会像潮水般涌来，但请你努力汲取这些知识。那么，距离又如何影响不同作物的种植和培育呢？对一种作物的耕作和修剪又是如何对另一种作物产生正面或负面影响的呢？这些问题正逐渐浮现出来。

你可能会说：“等等，让我先消化一下。”这种反应再正常不过了，毕竟时间因素会影响种植轮作，还有各种外部因素会带来潜在的波动性。所有这些都需要平衡，才能避免所有软件的天敌：随时间推移而无序增长。其他的“花园”培育案例能帮助你的“作物”在恶劣环境中存活下来。这一方法之所以行之有效，是因为它凝聚了众多著名软件专家(或者说是“园艺师”)数十年的研究和开发成果。

现在，尽情吸收这些知识养分，来开发并培育出卓越的软件吧！

——Vaughn Vernon

推荐序一

成功的软件系统会不断发展和演进，比如增加新的特性和功能，并支持新的技术和平台。但随着时间的推移，它们是否会不可避免地变成一个难以维护的“大泥球”呢？

鉴于复杂的软件系统是由多个相互关联的、各司其职的功能模块组成的，耦合的存在的确是不可避免的。但是模块之间的通信方式及它们共享信息的方式会影响我们对其做出更改的能力。

本书作者在介绍模块耦合和共生性的最初设计理念后，又为我们提供了思考耦合各维度(集成强度、波动性和距离)的全新思考方式。接着，他带领我们深入理解耦合，并提供一个完整模型，来帮助我们在设计或重构系统各个部分时评估耦合选项。大多数作者只用一个段落或一页纸解释耦合，而本书作者却为此专门写了一本书。

本书作者阐述了各种降低耦合的方法。不过耦合必然有害吗？当然不是。但我们也不该因此掉以轻心。本书的最后一部分介绍了“平衡耦合”的概念，同时提出了一套思考流程，指导开发者在对系统耦合关系进行“重新平衡”时，全面分析由此带来的设计影响。

感谢本书作者坚持撰写这本全面论述耦合、平衡和重新平衡(设计总是涉及权衡取舍)的著作，为我们提供了大量新颖的、见解深刻的新思路，来指导我们构建和重构复杂系统，使其保持正常运行和具备可演进性。本书让我充满希望：在细致的设计者手中，软件系统无序增长的态势将得到有效遏制。

——Rebecca J. Wirfs-Brock

推荐序二

软件设计的真谛并不在于那些具体的构建元素本身(如函数或类)，而在于藏在它们中间的“缝隙”。刚开始学编程时，你可能只学会了如何创建各种元素：函数、类型、类、模块、软件包、服务等。但即便掌握了这些，你依然没有掌握软件设计的真谛，你只是会“构建”这些元素，还不会“设计”整个系统。因为真正的设计发生在这些元素之间的“缝隙”里。

设计的目的就是让未来的变化更容易。那些具体元素(函数、类等)就是变化本身，而设计则是为这些新元素——无论是函数、类型、类、模块、软件包还是服务——预留出合理的空间，让它们能够顺畅融入系统，既不破坏原有的平衡，又能提供新功能。

作者的洞察力令人叹服，他系统梳理并归类了软件中这些至关重要的“缝隙”——那些连接点、接口，以及通常被忽视的、位于元素之间的“灰色地带”。若你渴望的不只是对代码进行修修补补，而是追求修改时的便捷与高效，那么作者总结的这套术语体系将是你不可或缺的指南，堪称软件缝隙的“词典”与“术语宝典”。

作者深知，专家是通过实践并不断反思来学习的。因此，本书中每章末尾的复习题正是为那些愿意投入努力、深入钻研的读者铺设的学习台阶。

承蒙Vlad邀请我推荐本书，我就借此机会对词汇稍加说明。Vlad使用的“集成强度”(integration strength)对我来说实际上就是“耦合”的意思，即各元素之间相互关联、相互影响的关系。而他用“耦合”表示运行或编译时元素之间更广泛的连接关系。这虽然不是什么大问题，但我觉得有必要指出这一点。

话虽如此，我还是由衷地推荐读者阅读本书。不对，应该是学习本书。当书中提到关于某种“缝隙”或连接的内容时，不妨在自己或他人的代码中寻找一下，尝试各种变体操作，调整更改时机，观察它的影响，然后阅读其他有关“缝隙”的内容，进行对比，深入研究。

随着时间的推移，你的软件必须是越来越容易更改。若掌握了本书中的概念和技能，你将可以轻松实现这一目标。

——Kent Beck

加利福尼亚州，旧金山市

译者序

大模型时代推动了AI Agent的快速发展。在Agentic AI系统中，大模型作为软件系统的决策“大脑”，智能体通过规划、记忆、交互、动作、安全等方式与物理/虚拟世界交互，实现决策。其中，规划模块在记忆模块的帮助下生成策略和动作计划，从而实现明智的决策；动作模块执行这些具身动作，并根据实时环境反馈调整动作，以给出情境适当的响应；记忆模块作为累积知识的存储库，促进持续学习和改进；交互模块实现智能体与人类、其他智能体及环境之间的有效沟通和协作；安全模块贯穿于大模型智能体的操作中，确保对威胁进行主动防护，并保持数据和过程的完整性和保密性。以上仅是单智能体大模型形成的软件系统的常见场景。

在大模型智能体编排器的作用下会形成更复杂的工作流，甚至出现不同角色下的多智能体。多智能体通过大型基础模型、知识相关技术、人机交互技术、数字孪生技术、多智能体协作技术等关键技术来实现复杂的大模型软件系统，每部分关键技术承担极其复杂的责任：①大型基础模型(如GPT-5和DeepSeek等)充当大模型智能体的大脑，使其具备高级模式识别、先进推理和智能决策能力，提供大模型智能体的认知能力；②知识相关技术通过引入知识图谱、知识库和RAG系统增强大模型智能体，使智能体能够访问、利用和管理庞大的外部知识源，确保其动作既知情又符合上下文；③人机交互技术通过NLP、多模态接口及增强/虚拟/混合现实，实现人类与智能体之间的无缝交互，促进动态和自适应交互；④数字孪生技术允许物理实体与大模型智能体的数字大脑之间通过智能体内部通信进行高效且无缝的数据和状态同步；⑤多智能体协作技术通过智能体间通信，使大模型智能体能够高效合作，共享数据、资源和任务，通过制定合作、竞争和竞争合作等策略解决复杂问题。在此基础上，大模型软件系统还需要与物联网、传感器、机器人等硬件设备无缝集成，也需要与应用App集成，形成完整的大模型智能体软件系统体系架构。

以上复杂的软件开发场景给软件需求分析、功能设计、编写代码等方面带来了诸多困难和挑战。多系统交互，多模型交叉场景是我们未来不得不面对的困难。基于此，功能层次、模块层次、系统层次、集成平台层次就需要一套技术方法论来解决在以上场景中遇到的挑战。这就是本书讨论的“耦合”。软件开发松散耦合理论是我们常提及的软件设计思想，甚至还出现了很多原则。但在实际过程中用起来极其困难。

翻译本书的动机，源于我对现代软件工程中复杂系统设计问题的深刻认识和密切关注。在大模型和人工智能技术快速发展的背景下，软件工程正在从工具层次向方法论层次转型。耦合问题不仅在传统的软件开发中至关重要，在大模型驱动的软件设计中更是核心议题。本书作者具有丰富的实践经验，从独特的视角为我们提供了一种系统化的方法来理解和管理耦合，从而在复杂的系统中实现更高效、更优雅的设计。

本书的出版填补了复杂软件耦合设计方向的空白。通过本书，能够看到作者对耦合问题的全面思考。他从复杂性科学的角度重新定义了耦合的内涵，并通过理论与实践相结合的方式，揭示了如何在软件设计中实现复杂性与模块化的平衡。本书的核心思想是在设计复杂系统时，不盲目追求解耦，而应理解耦合的来源、性质和作用，从而在多维度上做出合理的取舍。

在翻译过程中，我深刻体会到，耦合问题并不仅仅是技术问题，更是设计哲学的问题。本书的写作风格严谨而不失幽默，内容深入却不晦涩，每一章节都体现了作者对软件工程的热爱和对复杂问题的洞察力。这种风格让我在翻译中尽可能反映作者的原意，同时结合中文读者的阅读习惯，力求使内容更易于理解和接受。

无论你是一名初入职场的开发者，还是经验丰富的架构师，本书都能为你提供全新的视角。从耦合的基础理论，到多维度的解析方法，再到实践中的优化技巧，本书为我们绘制了一幅系统化的知识地图，帮助我们在复杂性与模块化之间找到最佳平衡。接下来从耦合的本质出发，重新思考软件设计的未来。本书也为大模型和Agentic AI时代设计复杂系统提供了技术支撑，是每个程序员必备之书。

在本书翻译的过程中，西南交通大学外国语学院王艺锦、成都市文化艺术学校吴文英、华南理工大学计算机学院郭甲赟参与了本书的翻译和审校工作，感谢他们为本书付出的一切努力。最后，感谢清华大学出版社的编辑，他们做了大量的编辑与校对工作，保证了本书的质量，使得本书符合出版要求。在此深表谢意。

由于本书涉及内容广泛、深刻，加上译者翻译水平有限，本书难免存有不足之处，恳请各位读者不吝指正。

译  者

作者简介

Vlad Khononov童年时代想开发自己的计算机游戏，因此在8岁时，他就开始阅读BASIC编程书籍。尽管他至今尚未发行过一款游戏，但软件工程已成为他的爱好和职业。Vlad具有20多年的行业经验，曾在不同规模的公司任职，职位从网站管理员到首席架构师不等。作为顾问和培训师，他目前帮助公司理解其业务领域、疏理遗留系统并攻克复杂的架构难题。

Vlad同时活跃于媒体领域，担任作者和主题演讲者。除了你手中正在阅读的这本书，他还撰写了Learning Domain-Driven Design(O'Reilly，2021)，该书已被翻译成8种语言。作为演讲者，Vlad曾在全球多个顶尖的软件工程和架构会议上发表演讲。他声名远扬，善于用简单易懂的语言解释复杂概念，技术行业和非技术行业的听众都能从他的演讲中受益。

译者简介

郭涛，主要从事计算数学、人工智能、现代软件工程和数智农业等前沿交叉研究。出版了40多部著(译)作，包括《重构的时机和方法》《函数式编程图解》和《函数式和并发编程》。

前言

软件设计类书籍通常仅会用几页篇幅讲述耦合。只在极少数情况下能看到有一整章专门讨论这个主题。然而，无论潮流如何翻涌变换，我敢打赌，无论是过去、现在还是将来，耦合永远都与我们息息相关。如果不信，你只需花点时间打听打听业界对此的议论就知道了。随处都可以听到“耦合不好”的怨言。但“耦合”到底是什么？它总是那么糟糕，还是到了某个临界点才变得非常糟糕？你能衡量它吗？若能，如何衡量？自从我成为一名软件工程师后，就在一直寻找这些问题的答案。但我所遇到的只是千篇一律的“避免耦合！”或“这种架构模式可以让你避免耦合！”，还有更糟糕的，“避免耦合的唯一方法就是使用我们的产品！”之类的说辞，简直令人唏嘘。

大约在2014年，又一种“解耦救星”出现了，那就是微服务。我甚至还记得某次会议的幻灯片上写着“微服务是解耦的架构”。当时听到的全是“微服务这个”“微服务那个”之类的言辞，但那时没人能真正说清楚微服务到底是什么。但这并没有阻止我们去尝试。在微服务/解耦大潮的推动下，我们决定“解耦”所负责项目中的一切组件。为此，我们围绕业务实体设计微服务，每个API都类似于CRUD(创建、读取、更新和删除)操作。我们声称每个实体都可以独立演进。结果呢？惨败。更准确地说，是史诗级的惨败。

然而，这个失败的项目却让我因祸得福。它让我有机会搞清楚为什么号称能解耦的方案会引发“耦合灾难”。我必须把它弄明白。因此，我开始阅读所有能阐释如何更好地实现微服务的论文和书籍。最终，我找到了一个解释。Structured Design(Yourdon和Constantine合著，出版于1975年)中的第6章描述了我们犯的所有设计错误，这一章的标题正是“耦合”。

我的软件设计耦合之旅就此开始。我想了解我们曾经知道但已遗忘的一切。几年后，所有关于耦合的知识碎片逐渐拼合成一幅完整的图景。我所学到的一切开始形成一幅清晰连贯的画面：一个有关耦合如何对软件项目产生影响的三维模型。渐渐地，我开始在日常工作中应用这个模型。它真的有效！更重要的是，它彻底改变了我对软件设计的认知。

在某个时刻，我忍不住想和大家分享我的发现。于是，我在2020年欧洲领域驱动设计大会上发表了演讲，题为“在分布式系统中平衡耦合”。当我走下讲台时，皮质醇和肾上腺素在我的血液中仿佛召开了一场“压力荷尔蒙大会”。我唯一记得的是，Rebecca Wirfs-Brock告诉我必须进一步完善和拓展这些想法，并为此写一本书。面对Rebecca Wirfs-Brock的建议，我怎能反驳？

我撰写本书的原因与我当年在会议上做那个演讲是相同的。我们曾经拥有但已遗忘的知识太重要了。所以，如果你正在阅读这些文字，这意味着经过了多年的艰辛努力，我终于赶在这本书把我压垮前完成了它。我由衷地相信，这些内容能像曾经帮助我那样给你带来启发。

读者对象

在我撰写这篇前言时，出版社的样式指南要求我“精准界定目标读者群体，避免冗长列举”。好的，那么本书的目标读者是所有从事软件开发的人。

无论你是初级、高级还是首席软件工程师或架构师，只要你的工作需要在任何抽象层次上做出软件设计决策，耦合就会影响你的工作成效。学会驾驭耦合对于构建模块化和可演进系统至关重要。

本书内容

本书内容分为三个部分。

第Ⅰ部分：耦合。本书第Ⅰ部分探讨整体情况，即耦合如何融入软件设计、复杂性和模块化的背景之中。

第1章的前半部分阐释什么是系统、如何构建系统，以及耦合在系统中所扮演的角色。该章的后半部分将重点转向软件系统，并介绍了后续章节中用于描述耦合的术语。

第2章首先帮助我们了解复杂性以便进行规避。为此，该章介绍了Cynefin框架的基本原则，该框架精确定义了复杂性。

第3章将讨论重点转移到普遍的系统，尤其是软件设计的复杂性。你将了解软件系统复杂性的根源，以及这与耦合的关系。

第4章重点讨论我们追求的目标：模块化。该章定义了模块化和软件模块的概念。最重要的是，该章讨论了耦合：它是引导系统走向复杂性或模块化的关键。

第Ⅱ部分：维度。本书第Ⅱ部分主要聚焦于耦合。你将了解耦合影响系统的不同方式，以及用于评估其影响的多种模型。

第5章回溯过去，介绍软件设计中第一个用于评估耦合的模型，该模型于20世纪60年代末提出，但至今仍然适用。

第6章介绍反映耦合另一层面的模型：共生性。你将了解模块“共同诞生”的含义以及这种共生关系的不同程度。

第7章结合结构化设计的模块耦合和共生性耦合形成了一个综合模型：集成强度。你还将学习如何使用这一模型评估系统各组件之间共享知识。

第8章将重点转向空间维度。该章阐述了模块在代码库中的物理位置如何影响它们之间的耦合。

第9章将重点转向时间维度。该章将讨论软件模块更改的原因、模块的波动性在整个系统中的传播，以及评估模块预期更改率的方法。

第Ⅲ部分：平衡。通过将耦合的各个维度转化为设计模块化软件的工具，该部分将前两部分的主题有机结合在一起。

第10章探讨耦合的各个维度相结合所带来的见解。该章还介绍了平衡耦合模型：一个用于评估耦合对整体系统影响的整体模型。

第11章讨论软件系统的战略性演进、演进带来的更改以及通过重新平衡耦合作用力适应更改的方法。

第12章继续讨论系统演进的话题，重点讨论最常见、最重要的更改：增长。该章结合了其他行业甚至自然界的知识，揭示指导软件设计的基本设计原则。

第13章从理论转向实际应用，讨论案例研究以展示如何运用平衡耦合模型改进软件设计。这些案例研究还表明，平衡耦合模型可以在一些著名的架构风格、设计模式和设计原则中得到体现。

第14章总结本书内容，并就如何在日常工作中应用所学原则提供最终建议。

案例研究和WolfDesk

本书立足于实践。你读到的所有内容都经过了实践验证，并被证实在多个软件项目和业务领域中有效。这种实践验证在每一章的案例研究中都有体现。我将那些来自实际项目一线的事件改编成关于一家虚构公司WolfDesk的案例研究。尽管这家公司是虚构的，但所有案例研究均源自真实的项目。以下是对WolfDesk及其业务领域的简要描述。

WolfDesk

WolfDesk是一家提供桌面管理系统的服务商。若一家初创公司需要为使用者提供服务，WolfDesk的解决方案可以让公司立即投入运行。

WolfDesk采用了一种有别于其他竞争对手的支付模式。它不是按使用者数量收费，而是允许租户根据需要设置任意数量的使用者，费用则根据每个计算周期内打开的服务案例数量来计算。该模式不设最低收费限制，而且每月案例达到一定数量时，系统会自动提供折扣。

为防止租户通过重复使用现有服务案例来利用这一商业模式，系统通过生命周期算法自动关闭闲置服务案例，从而鼓励使用者开启新案例来获得更多服务。此外，WolfDesk部署了一个欺诈检测系统，该系统可分析消息内容，并识别在同一服务案例中讨论不相关主题的情况。

为了帮助租户精简服务相关的工作，WolfDesk推出了“服务自动引导”功能。该功能会分析新的咨询内容，并尝试从租户的历史记录中自动找到匹配的解决方案。

该功能有助于进一步缩短案例周期，鼓励使用者就更多问题创建新的案例。

管理界面允许租户自定义服务案例类别的可能值，以及需要服务的产品列表。为确保服务案例仅在工作时间内分配给代理，WolfDesk允许使用者为不同部门和组织单位安排不同的轮班计划。

本书的参考文献请扫描以下二维码下载。

引言

试想有一款顶级的瑞士手表，它是机械工程和传统手工艺品的完美结合，堪称杰作。显然，它的主要功能是精确计时。根据瑞士官方天文台测试认证机构的要求，在为期15天的测试期间，手表平均每天的误差不得慢于4秒或快于6秒，但这还不是全部。现代手表还包含诸多复杂功能，如计时器、日期显示、月相显示或同时显示多个时区的时间。所有这些都是由数以百计的微小组件实现的。每个组件，无论多小，都在整个机械装置中发挥着至关重要的作用。

但这还不够。

组件之间的交互作用必须精确无误。例如，若润滑不足会导致连接处过紧，过多摩擦就会使手表运行走慢；反之，若组件润滑过度，齿轮和弹簧的运行就会过于松散，导致手表走快。要使手表长期保持精准，组件之间的交互必须达到完美平衡。

这与软件设计中的耦合类似。

现代软件系统由数百甚至数以千计的模块组成。即使某个模块完美地实现了其功能，也是不够的。要创造价值，必须将它集成到系统中，与其他组件耦合。正如手表的物理连接需要精妙的平衡一样，软件模块的集成也必须经过审慎考虑。若耦合过于松散，系统可能变得脆弱且难以控制；若耦合过于紧凑，系统就会缺乏实现高效性能和未来适应性所需的灵活性。要使系统兼顾稳定性和适应性，完美的平衡是至关重要的，正如在精密制表界中那样，需要细致入微，和谐一致。

但如何才能实现平衡呢？

这就是我们要学习的内容。本书计划实现两个主要目标。其一，全面阐释耦合，以及它在软件设计中的各种表现形式。其二，通过学习评估耦合的多维作用，你可以发现一种有趣的可能性，即把历来被贬低的耦合概念转变为一种建设性的设计工具。这一工具有助于引导系统摆脱复杂性，走向模块化，体现平衡耦合的原则。

它为何如此重要？

高端机械表不仅是计时装置，它们更是能够随着时间的推移积累显著价值的有形资产。成功的软件系统也是如此。软件系统的价值不仅反映在当前的功能上，还体现在其演进、增长和满足未来需求的能力上。正如你将在本书中学到的，高效的跨组件交互设计对于构建经得起时间考验的系统至关重要。

从根本上说，这一切都与耦合有关。

虽然本书的重点是耦合，但其整体范围广泛。耦合影响着我们所做的一切：无论是编写函数、设计对象模型，还是构建分布式系统，你所学到的原则都具有普适性。具体而言，你可以学会识别和评估耦合在多个维度上的影响。你可以理解这些耦合作用力之间如何交互，并利用它们做出明智的设计决策。本书将探讨为什么某些设计决策会提高复杂程度，而另一些则会提升系统的模块化。本书将带你超越对软件设计问题常见的“视情况而定”的模糊回答，拨云见日，让你真正明白这个“视情况而定”中的“情况”到底是什么。

致谢

我要向Vaughn Vernon致以最深切的谢意；没有他的鼎力帮助，这本书不可能完成。Vaughn不仅为我提供了难得的机会，让我能够将这些想法付诸文字，还在整个写作过程中给予我大力支持。感谢他在我需要帮助时始终在我身边，为我提供宝贵的建议和见解，这些都极大地丰富了本书的内容。

Haze Humbert是本书的守护天使，或者更正式地说，他是本书的执行编辑。本书的编写历时四年，我知道这四年对Haze来说并不轻松。所有可能会出错的地方都出了错，甚至更多。Haze，你是我认识的最有耐心的人之一。谢谢你让这本书得以实现，感谢你在最关键的时刻给予我支持。

写完这本书后，我如释重负！然而，那仅是一场战争的结束。为了赢得这场战争，还需要完成印刷前的准备工作，这个过程充满了各种意想不到的挑战。我要感谢本书的内容制作人Julie Nahil，她始终站在我的一边，帮助我按照自己的设想来排版。

这本书横跨软件工程的不同时代和多个学科领域。这是我参与过的最具挑战性的项目，若没有这么多人的帮助，这本书不可能顺利付梓。我要感谢在本书写作过程中曾咨询过的相关领域专家[  所有人名列表均按姓氏字母顺序排列。]：Alistair Cockburn、Gregor Hohpe、Liz Keogh、Ruth Malan、David L. Parnas、Dave Snowden和Nick Tune。

衷心感谢审稿人审查早期未经编辑的初稿，他们的反馈意见对完善书稿起到了至关重要的作用。他们是：Ilio Catallo、Ruslan Dmytrakovych、Savvas Kleanthous、Hayden Melton、Sonya Natanzon、Artem Shchodro和Ivan Zakrevsky。

最后但同样重要的是，我要感谢两位特别的人：Rebecca J. Wirfs-Brock和Kent Beck。他们教会了我很多，能够邀请他们担任本书推荐序编写者是我莫大的荣幸。感谢两位为本书撰写的热情洋溢、鼓舞人心的推荐语！