《领域驱动设计》系列名著作者重磅新作｜面向数字化转型企业的全新架构设计理念｜国内软件工程及开发模式众大咖作序力荐｜打破业界窠臼反唯微服务论之方法论大成

译者简介
娄麒麟，Thoughtworks专家级咨询师，海外项目交付安全负责人，思特沃克技术雷达第28期中文主编。擅长函数式编程、事件驱动架构、云原生设计、风险管理，以及DevSecOps。有着近10年的研发团队管理经验，曾主导某大型跨国银行的微服务改造工程，和某头部科技金融公司的遗留系统改造工程。近来在研究产品研发的全生命周期风险控制和AI赋能。

马建勋，Thoughtworks专家级咨询师，IT从业10余年，曾领导和参与多家海内外不同规模项目的研发和改造，涉及ERP、互联网、银行等领域。主要研究兴趣在于敏捷开发，领域驱动设计，软件架构演进以及项目管理。

姚琪琳，Thoughtworks专家级咨询师，遗留系统现代化解决方案负责人，极客时间《遗留系统现代化实战》专栏作者，技术书籍译者，CAC认证敏捷教练。拥有超过16年的软件行业从业经验，对开发、设计和架构有着深入的理解。擅长领域驱动设计、敏捷软件开发、整洁代码和重构，并通过理论指导、实战演练等方式为企业研发团队赋能。参与翻译或审校多本技术书籍，包括《重构到微服务》、《领域特定语言》、《.NET性能优化》、《深入理解C#》等。

张渝，Thoughtworks专家级咨询师。曾领导和参与多个海内外项目，涉及私有云，支付，视频等多个领域。擅长敏捷软件开发，领域驱动设计，云原生设计，测试驱动开发以及重构。

前言
很可能你的组织的赚钱方式与传统意义上的软件销售无关，未来也可能不会与软件直接相关。但这并不意味着软件不能在你的组织的营利中发挥重要作用。事实上，软件正是那些最具价值的公司的核心。
以FAANG（指Facebook、Apple、Amazon、Netflix和Google，Facebook现更名为Meta，Google现更名为Alphabet）为例。这些公司几乎都不直接出售软件，或者说软件销售不是它们的主要收入来源。
Facebook大约98%的收入来自向希望接触其社交网络用户的公司销售广告位。这些广告位之所以如此有价值，是因为Facebook的平台极大地增强了用户之间的互动。用户关心其他用户和整体趋势，这使得他们持续关注人群、事件和社交平台。获取Facebook用户的关注对广告商来说价值巨大。
Apple主要是一家硬件公司，销售智能手机、平板、可穿戴设备和计算机。软件使这些设备的价值得以最大化。
Amazon通过多种途径产生收入，既作为在线零售商销售商品，也销售电子书、播客、音乐和其他订阅服务，还销售云计算基础设施。
Netflix提供电影和其他视频流媒体服务，通过销售不同等级的订阅服务来获得收入。该公司还通过DVD订阅服务赚钱，但随着视频点播的日益流行，这部分业务的下滑在预期之中。面向用户的软件运行在电视和移动设备上，视频流媒体是通过其进行增强和控制的。然而，真正的复杂性来自部署在亚马逊云上的系统，这些云系统提供了超过50种不同编码格式的视频，通过内容分发网络（CDN）提供内容，并在遇到故障时处理故障。
Google的收入也主要依赖于销售广告，这些广告展示在其搜索引擎的查询结果中。2020年，Google通过直接提供软件应用（例如 Google Workspace）获得了约40亿美元的收入。但与传统的软件不同，Google Workspace不需要被安装在用户的计算机上，而是以软件即服务（SaaS）的模式在云上运行。根据最新的报告，Google占据了近60%的在线办公套件市场份额，超过了微软。
从这些行业领导者的经验可以看到，组织并不需要销售软件就能获得领先市场的收入。然而，为了在当前和未来的业务中表现优秀，组织确实需要利用软件。
此外，组织要通过软件推动创新，就必须认识到一群优秀的软件架构师和工程师的重要性。这些顶尖的人才因其重要性而变得难以招聘。可以将这个情况比作WNBA或NFL的选秀：前20名选手对球队来说至关重要。当然，这并不适用于所有的软件开发者。有些人满足于“打卡上班”，支付他们的房贷，并尽可能多地挤出时间看 WNBA和NFL的电视节目。如果这些人是你所希望招聘的，我们强烈建议你立即停止阅读本书。然而，如果你希望做出有意义的改变，那么请继续阅读。
对于那些追求卓越和加速创新步伐的组织来说，仅仅理解优秀的软件开发人员的价值是不够的。如果一家企业想要通过软件创新来主导所在行业，那么它必须认识到这些软件架构师和工程师是“新的决策者”（The New Kingmaker）——这个概念由Stephen O’Grady在他2013年出版的著作The New Kingmakers: How Developers Conquered the World（见参考文献0-3）中提出。为了真正成功地开发软件，所有有雄心壮志的企业都必须理解是什么驱使这些开发人员超越了常规的软件开发方式。他们渴望创造的软件远非平凡之作。最有价值的软件开发人员希望创造能够决定行业未来的软件，这正是你的组织在招聘过程中应该传达的信息，以便吸引最优秀的人才和有足够动力做到最好的人才。
本书适合C级管理者和其他高管，以及所有职位和级别与软件开发相关的人员。如果软件交付能直接导致战略差异或支持战略差异，那么其负责人都应该了解如何通过软件推动创新。
作者发现，今天的C级管理者（如CEO）和其他高管与他们几十年前的前辈有所不同。他们中的许多人非常熟悉技术，甚至可能被视为业务领域的专家。他们对改善特定领域有深远的洞见，并成功吸引了其他高管和理解创始人目标的技术专家。以下人员可能会发现本书特别有用。
那些紧跟技术愿景的CEO，比如创业公司的CEO，以及希望洞悉软件在未来企业中的作用的CEO。
那些致力于推进和实现软件开发差异化的CIO。
那些通过创新引领软件愿景的CTO。
高级副总裁、副总裁、总监、项目经理等，他们负责实现愿景。
可从本书中获得启示的首席架构师。本书也是激励软件架构师和高级开发人员团队以商业思维和有针对性的架构推动变革的重要指南。
所有级别的软件架构师和开发人员。他们需要发自内心地树立商业思维，意识到软件开发不仅仅是赚取高薪的手段，更是通过软件创新实现卓越成就的途径。
本书包含了所有软件专业人士必须掌握的重要信息，通过消化、吸纳和实践本书探讨的专业技术，可以实现持续创新。
本书并非一本专注于具体实现细节的书。我们将在接下来的图书Implementing Strategic Monoliths and Microservices中提供更多实现细节。本书主要聚焦于软件如何作为业务战略的一部分。
对于缺乏软件行业深度知识或经验的领导者来说，本书是极具吸引力的。它通过阐述每个软件举措应有的愿景、有针对性的架构设计、战略的设计和实现来实现有效的信息传达。同时，我们强烈建议读者避免有意或无意地将复杂性引入软件。推动变革的关键在于提供超出用户或客户期待的软件。因此，本书旨在挑战那些坚守现状、保护自己工作岗位的人，鼓励他们接受新一代的思想、方法和工具，以期成为未来产业的创新者。
本书的作者曾与许多不同的客户合作，亲眼见证了软件开发中的负面现象。比如，有人把保住工作和捍卫自己的地盘视为主要目标，而非推动企业的创新发展。许多大型企业如此庞大，存在复杂的管理和汇报架构。这些企业同时推动多项举措，但“愿景—实现—接受”的路径并非顺畅无阻。基于此，我们试图唤醒人们，让他们认识到“软件正在吞噬世界”的真实性。本书的内容带有现实主义色彩，表明创新可以通过逐步进行的实践来实现，而不必寄希望于瞬间的巨大飞跃。
尝试创新总是伴随着风险。然而，从长远来看，完全不冒任何风险可能更加危险。下面的图P.1清楚地说明了这一点。
正如Natalie Fratto指出的（见参考文献0-1），通常情况下，冒险的风险随着时间的推移而减少，但什么都不做的风险却会随着时间的推移而增加。在她的TED演讲中（见参考文献0-2），我们可以看到Natalie作为一名风险投资人的观点，她解释了所投资企业创始人的类型。她说，许多投资者寻找具有高智商（IQ）的创始人，而另一些投资者则寻找具有高情商（EQ）的企业家，而她主要寻找那些具有高适应性指数（AQ）的人。实际上，创新需要极高的适应性，这个观点在本书中以多种形式被反复强调。从实验到发现，再到架构、设计和实现，都需要适应性。除非具有高度的适应性，否则冒险者很难成功。
在讨论软件创新的主题时，我们不可避免地会涉及迭代和增量开发，这是一个具有高度争议的主题。事实上，某种形式的敏捷论调是无法回避的。本书避免了宣传特定的敏捷或精益方法。遗憾的是，大多数声称采用敏捷思想的软件公司和团队，并不真正理解如何做到敏捷。我们的愿望是强调理解而非采用。敏捷的原始理念非常简单：它专注于协作交付。如果保持简单，敏捷可以非常有用。然而，这并不是本书的主要关注点。我们只想指出，采用“复杂”的敏捷可能会带来的损害，以及敏捷方法如何提供帮助。关于我们如何看待敏捷方法能提供的帮助的简短讨论，请参见第1章中的“善待敏捷”部分。
考虑到我们的背景，一些读者可能会惊讶地发现，我们并不将本书视为一本关于领域驱动设计（DDD）的书。当然，我们确实介绍了领域驱动设计的方法和优点，以及如何使用它，但我们并没有将自己局限于DDD，而是提供了更广泛的观点。本书旨在应对这样一个现实需求：“软件正在吞噬世界，因此我们需要聪明地与时俱进，进行创新，做出基于实际目标的明智架构决策，否则我们就会落后。”我们解决的是多年与各种公司打交道遇到的实际问题，特别是我们过去五到十年观察到的问题。
我们有点担心，用来提醒大家的鼓点听起来可能会太响。然而，对比其他由科技驱动的行业周围的鼓点，我们认为自己的声音是必要的。当其他人在高山上不断敲打着“下一个被高估的产品就是银弹”的鼓点时，我们觉得至少需要一些对应的声音，用来提醒人们，大脑才是最好的工具。我们的目标是展示出真正的创新来自思考和反思，而不是购买通用产品或者不断投入技术力量来解决难题。所以，请把我们看作在相邻的另一座山上敲打着“成为科学家和工程师”的鼓点的人，我们希望你能通过创新和独特的方式超越平凡。确实，我们在这个过程中付出了很多汗水。如果我们强烈的鼓点声给读者留下了一些深刻的印象，那么我们认为自己已经实现了目标。如果这种刺激能够引导我们的读者获得更大的成功，那就再好不过了。
图P.2展示了本书大多数架构图中使用的建模元素。这些元素的规模从大到小不等，取决于图表的主题。其中一些元素来自事件风暴部分。
在图P.2中，上半部分是战略和架构元素：业务/限界上下文是业务能力和知识领域的软件子系统及模型边界；大泥球是许多企业所处的“无架构”状态；端口和适配器表示既有基础功能又富有灵活性的架构风格；模块是包含软件组件的有独特名字的包。
图P.2的下半部分描绘了8种战术组件类型：命令引起状态转换；事件捕获和记录跨子系统边界的状态转换；策略描述业务规则；聚合/实体保存状态并提供软件行为；用户角色与系统进行交互，通常代表一个角色；视图/查询收集和检索可在用户界面上呈现的数据；进程管理多步操作，直至操作全部完成；领域服务提供跨领域的软件行为。它们存在于子系统内部，有时会流向其他子系统。