分类： 架构

发布于

[ddd_java_1]基于领域驱动设计的Java开发

第1章 理解领域驱动设计

引言

软件已成为业务成功不可或缺的战略要素，渗透到现代组织的各个层面。企业日益依赖技术来提升效率、交付价值并保持竞争力。这种日益增长的依赖性凸显了能够使软件解决方案与业务目标紧密契合的开发实践的重要性。领域驱动设计【Domain-driven design (DDD)】 应运而生，正是为了满足这一需求，它提供了一种直接的方法来弥合业务期望与技术实现之间长期存在的鸿沟。它使团队交付的软件，能精准、清晰且持续地支撑和驱动业务成果。
随着商业环境变得更加动态和多面化，将领域知识转化为有效软件解决方案的挑战日益凸显。一个常见的问题在于相关方的设想与软件最终交付成果之间的错位。行业观察指出许多软件项目的关键失败点在于：过度关注未经验证的计划和设计、客户期望模糊或不断变化、实施过程中出现不可预见的复杂性，以及产品与工程团队之间协作不力。这些问题常常导致技术工作严重偏离业务目标。
在当前工具生态中，选择的悖论进一步加剧了这种脱节。尽管开发团队可以接触到前所未有的丰富框架和技术，但过多的选择可能导致决策瘫痪、效率低下，并使人忽视真正重要的东西。在此背景下，复杂性成为一种负担而非优势，使得在整个开发过程中保持清晰度和业务对齐变得越来越困难。
这正是DDD实践发挥其作用之处。通过将开发工作立足于业务领域，并鼓励有意的协作建模，DDD提供了一个交付能反映相关方真实需求解决方案的框架。DDD并不规定特定的架构或技术栈，而是倡导清晰性、共同理解和长期可维护性，而不受技术约束的限制。
本章介绍了DDD背后的基本原理，解释了它为何重要以及它旨在解决哪些问题。它为后续更深层次的技术和战略主题奠定了基础。掌握DDD不仅仅是学习模式——它始于理解其原则，特别是指导从发现到实施的战略和战术维度。本章是这段旅程的第一步。

结构

在本章中，我们将探讨以下主题：

  •   领域驱动设计的重要性
  •   连接业务目标与技术实现
  •   核心概念与方法论

    学习目标

    本章旨在为理解DDD在软件开发中为何至关重要奠定基础，重点关注那些常导致项目失败的挑战，例如业务与技术团队之间的错位、不明确的客户期望以及不必要的复杂性。通过探讨DDD的原则，本章展示了它如何提供一种结构化方法来弥合业务与技术之间的差距，促进协作，并确保软件解决方案与现实需求保持一致。本章不深入探讨实现细节，而是介绍DDD背后的逻辑，为全书深入讨论其战略和战术应用做好铺垫。

    领域驱动设计的重要性

    DDD能够通过以下方式应对常常导致软件项目脱轨的常见挑战：

  •   对齐业务与技术团队：DDD提出的实践可以澄清业务需求，并确保技术实现满足这些需求和期望。
  •   澄清客户期望：减少误解和模糊的需求，从而产生真正满足相关方目标的软件。
  •   简化解决方案设计：将系统的复杂性分解为可管理的部分，可以减少常常令人难以招致、拖慢进度并使长期维护变得困难的复杂性。通过掌握正确的实践，团队可以从更简单的设计中受益，从而降低软件维护的难度。
  •   改善跨团队协作：当业务和技术团队不能紧密合作时，关键的商业见解可能在沟通过程中丢失。借助DDD，每个人都可以协作并开始朝着相同的目标努力。
    通过将软件开发建立在业务领域的基础上，并促进技术团队与业务团队之间持续紧密的合作，DDD实践可以使您的团队确保每个类、方法和变量都与核心业务需求正确对齐，最终让您能够控制最终产品的价值及其与相关方期望的一致性。
    DDD最显著的优势之一是其管理复杂性的能力。在软件开发工具和框架数量不断增长的世界里，开发人员迟早会感到选择过多而迷失业务目标。DDD通过一种结构化方法来应对，该方法允许将复杂的业务领域分解为可管理且重点突出的子域。这样，软件变得更容易理解和维护，同时确保开发过程与整体业务战略保持一致。
    此外，DDD强调通用语言的重要性，这是业务和技术团队之间一致使用的共享语言。共同的词汇可以最大限度地减少误解，并驱动项目所有参与者朝着相同的目标努力。开发过程转变为一种协作的跨团队努力，业务和IT部门可以共同创建并交付能够准确反映业务需求和目标的解决方案。
    现在，着眼于DDD在现实场景中的实际应用，我们可以参考那些精确性和团队对齐至关重要的行业。例如，在合规性和准确性至上的银行业，DDD确保贷款管理系统和交易平台的设计既满足法规要求，也满足金融专业人士的特定需求。在电子商务领域，DDD使得能够开发出快速适应不断变化的市场需求，同时保持无缝客户体验的平台。
    最终，DDD的重要性在于它能为软件开发过程带来清晰度和专注度。通过确保软件反映并支持业务的战略目标，DDD提高了解决方案的整体质量和商业价值。了解您工作所交付的价值，可以激励您在自己的项目中有效地实施DDD。在下一节中，让我们探讨DDD如何帮助弥合业务与技术团队之间的鸿沟，为您提供能够改善项目中跨团队协作的基础知识。

    连接业务目标与技术实现

    软件开发中最大的挑战之一是业务目标与技术实现之间的差距。这种差距常常导致误解、优先级冲突以及软件未能达到目标。DDD可以通过将领域专家融入开发过程来克服这一挑战。
    DDD的核心思想是让软件开发与其所支持的业务领域紧密对齐。开发人员不是依赖大量描述需求的文档，而是可以直接与业务专家（又称领域专家）合作，从而直接了解业务的核心活动、挑战和目标。这种紧密合作是一项关键实践，它使领域专家能够为更好、更明智的技术决策提供关键见解。
    弥合沟通鸿沟的一个关键方法是使用通用语言，即两个团队共享的词汇表。在协作中，团队定义并商定这些术语，随后这些术语在项目各阶段（从初始讨论到实施、验证及最终交付）持续一致地使用。这种方法可以最大限度地减少误解，通过减少错误和不符合要求的不正确交付来节省时间。
    DDD还鼓励团队围绕业务领域构建软件系统，通过以反映业务本身结构的方式来设计代码。这种方法使软件更直观、更易于维护，简化了行业中可能的变化在软件中的反映。
    通过运用DDD实践来弥合业务与技术之间的分歧，可以使组织能够创建技术上良好且与企业战略目标紧密对齐的软件。因此，可以创建出更有效、更高效、更有价值并为业务带来切实效益的软件解决方案。
    在本章的下一节中，我们将分解DDD的核心概念和方法论，让您更好地理解如何将理论应用到您的软件项目中。

    核心概念和方法论

    在深入探讨DDD之前，我们必须首先分解其主要概念及其含义。
    领域是指我们旨在转化为代码的特定主题或知识领域。领域的大小或复杂性不是问题，因为我们可以应用分治法将复杂领域分解为更小、更易于理解的子集。
    下图说明了软件开发中的这种分治方法。它直观地展示了软件开发中的知识如何分解为不同的领域，如数据库、文档和架构，并进一步细分为像SQL和NoSQL这样的子域。这种可视化分解有助于阐明DDD如何通过专注于特定的业务领域来鼓励理解和管理复杂性。

    图1.1：软件开发作为一个领域
    在DDD的语境中，业务领域是公司主要的活动领域，反映其核心提供的价值。例如，星巴克主要与咖啡相关，而亚马逊则在零售和云计算等多个领域运营。公司可以发展，随时间改变或扩展其业务领域。
    为了管理领域的复杂性，可以将其细分为子域。这些子域可以进一步分为核心子域、支撑子域和通用子域。
    鉴于软件工程师对客户业务知识有限，领域专家扮演着至关重要的角色。领域专家对业务复杂性有深刻理解，这些细节自然地成为其软件中的需求。
    注：最后的术语"设计"可能难以定义，常常与软件架构混淆。《软件架构基础》等经典著作将架构描述为那些难以更改的东西或设计，但这仍然是一个抽象概念，因为难以更改的内容会有所不同。Neal Ford的著作《Head First in Software Architecture》提供了更细致的观点，将架构和设计定义在一个光谱上，设计是关于做出决策来塑造软件系统的结构和组织，以管理复杂性并创建连贯、可维护的架构。
    下图展示了从软件架构到设计的决策光谱。它表示了设计与架构之间的紧密联系，以及设计决策如何可以是一个更轻松的定义，或者如何成为软件系统核心结构的内在部分。

    图1.2：架构与设计的光谱
    考虑到这一点，我们可以将DDD定义为对软件系统结构和组织做出的有意决策，旨在提取业务知识并将其转化为代码。
    DDD是语言无关的，可以用于任何编程语言、范式或框架构建的解决方案。虽然通常与面向对象编程和Java相关联，但DDD实践也适合根据项目需求选择的任何其他语言。
    提示：本书并非旨在取代关于DDD的经典文献，而是通过实践指导来补充它。像Eric Evans的《领域驱动设计：软件核心复杂性应对之道》和Vaughn Vernon的《实现领域驱动设计》这样的基础著作是必读的，即使它们看起来具有挑战性。
    DDD有两个主要组成部分：战略和战术。两者对于确保良好的技术质量和正确的业务对齐都至关重要。让我们探讨这两个方面的区别以及它们如何相互作用。

    DDD的战略层面

    DDD是所有开发工作建立的基础，其重点是加深对业务、其核心领域以及共同构成其运营的子域的理解。
    DDD中的战略着眼于大局，识别业务中最关键、应优先考虑并反映在软件中的领域。这不仅需要协作，更需要与领域专家建立伙伴关系，他们能够传达系统中需要捕捉的复杂性。战略方法使得开发过程中的每个决策都能基于对业务背景扎实、透彻的理解。它指导整个软件项目的结构和方向。

    DDD的战术层面

    DDD的战术层面涉及将战略见解实际应用到代码中。
    一旦业务领域和子域被明确定义，并且通用语言（领域的术语和关键概念）建立起来，DDD的战术层面就开始发挥作用。它包括实施特定的设计模式和编码实践，这些能够通过软件将战略愿景变为现实。战术确保软件架构与业务模型保持一致，因为领域的抽象概念被转化为具体的、功能性的系统组件。DDD战略的标准定义通过可操作的任务得到准确体现，例如创建实体、值对象、聚合和仓库。
    战略和战术在DDD中结合起来，形成了一种连贯的软件开发方法。这种方法在DDD中不仅是一种选择，更是一种必然。战略提供了总体愿景，并确保软件与业务需求保持一致，而战术则负责将这一愿景转化为可运行系统的实际工作。两者都至关重要；没有坚实的战略基础，软件可能无法充分应对业务的核心挑战；没有有效的战术，即使是最好的战略计划也可能在执行中失败。通过整合这两个方面，DDD使得能够创建技术上健壮且与业务高度相关的软件。
    提示：正如《软件设计哲学》中所解释的，战略型软件工程师明白，软件开发不仅仅是编写代码。相反，只关注战术可能弊大于利，从而获得"战术龙卷风"的绰号。
    虽然软件工程师很容易对DDD的战术方面感到兴奋，但重要的是要记住，有效的实施必须从战略开始。DDD的目标是提取业务知识并将其编码到软件中，这使得战略成为关键的第一步。在本书中，我们将探讨能够将您的DDD实践提升到新水平的核心战略和战术知识。

    本章小结

    本章解决了确保软件开发满足客户和相关方期望这一根本性挑战。通过探讨DDD的核心原则，我们展示了这种方法如何使软件与业务目标保持一致。我们强调了理解领域、做出有意的设计决策以及成功实施DDD所需的战略基础的关键作用。本章的要点包括：DDD如何确保开发与业务需求之间的对齐、领域和设计在将业务知识转化为软件中的作用，以及业务和技术团队之间协作的重要性。
    下一章将深入探讨战略DDD，探索如何有效地识别和分类领域与子域。这种战略洞察将为您提供工具，以做出明智的、与业务对齐的决策，确保您的DDD努力为客户带来真正的价值。
    要点总结

  •   DDD聚焦于业务对齐：DDD的主要目标是确保软件开发与业务目标保持一致并交付真实价值。
  •   常见的项目失败源于错位：诸如不明确的客户期望、糟糕的协作以及过于复杂的设计等问题常常导致软件无法满足业务需求。
  •   业务领域是DDD的核心：软件应围绕实际的业务领域构建，使用反映现实世界运作的概念和语言。
  •   协作是关键：通过共享的通用语言促进业务和技术团队之间的有效沟通，可以减少误解并改善软件成果。
  •   DDD兼具战略性和战术性：战略方面侧重于理解领域和子域，而战术方面则涉及实施反映业务需求的模式和结构。
  •   复杂性应被管理而非增加：DDD有助于将复杂系统分解为可管理的部分，确保软件保持适应性、可维护性并与不断发展的业务需求保持一致。
  •   本章为DDD奠定基础：本章并非涵盖所有细节，而是介绍DDD背后的逻辑，为您深入学习其战略和战术应用做好准备。

    选择题

    1.  DDD旨在解决的主要挑战是什么？
          a. 降低软件开发成本
          b. 使软件开发与业务目标保持一致
          c. 提高软件交付速度
          d. 增加软件项目的技术复杂性
          e. 增强软件界面的美学设计
    2.  以下哪项不是本章讨论的DDD关键焦点？
          a. 领域
          b. 设计
          c. 战术实施
          d. 战略基础
          e. 美学用户界面设计
    3.  为什么在DDD中拥有战略基础至关重要？
          a. 它有助于降低软件工具的成本。
          b. 它确保软件架构难以更改。
          c. 它使软件解决方案与业务目标紧密结合。
          d. 它只专注于开发的技术方面。
          e. 它消除了对领域专家的需求。
    4.  在DDD中，为什么业务和技术团队之间的协作至关重要？
          a. 为了增加项目的复杂性
          b. 为了确保软件按时交付
          c. 为了促进共同理解和语言，减少不必要的复杂性，并确保软件交付业务真正需要的东西
          d. 为了减少所需的技术资源，并在没有额外复杂性的情况下交付业务真正需要的东西
          e. 为了让技术团队可以独立做出所有决策
    5.  领域专家在DDD中的主要角色之一是什么？
          a. 为软件编写代码
          b. 提供深刻的业务知识以指导开发过程
          c. 管理项目的技术资源
          d. 设计软件的用户界面
          e. 创建详细的软件架构图

      答案

      题号 答案选项
      1 b
      2 e
      3 c
      4 d
      5 b

      参考文献

    6.  Sinek, Simon. Start with Why: How Great Leaders Inspire Everyone to Take Action, 2009.
    7.  McAfee, Andrew. Now Every Company Is A Software Company, Forbes Techonomy, 2011.
    8.  Quidgest. Every Business Is a Software Business, Quidgest Articles, n.d.
    9.  Forbes Technology Council. 16 Obstacles To A Successful Software Project (And How To Avoid Them), Forbes, 2022.
    10.  Schwartz, Barry. The Paradox of Choice: Why More Is Less, 2004.
    11.  Krill, Paul. Complexity Is Killing Software Developers, InfoWorld, 2012.
    12.  Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003.
    13.  Vernon, Vaughn. Implementing Domain-Driven Design, 2013.
    14.  Richards, Mark & Ford, Neal. Fundamentals of Software Architecture: An Engineering Approach, 2020.
    15. Ford, Neal. Software Architecture: The Hard Parts, 2021.
    16. Ousterhout, John. A Philosophy of Software Design, 2018.

加入我们的Discord空间
加入我们的Discord工作区，获取最新更新、优惠、全球科技动态、新版本发布以及与作者的交流机会：https://discord.bpbonline.com

发布于

[ddd_java_0-1]基于领域驱动设计的Java开发

基于领域驱动设计的Java开发

运用DDD原则构建可扩展与可维护的Java应用系统
奥塔维奥·桑塔纳 (Otavio Santana)
网址：www.bpbonline.com
2026年第一版
版权所有 © BPB Publications，印度
eISBN：978-93-65894-226
保留所有权利。未经出版者事先书面许可，本出版物的任何部分不得以任何形式或任何方式（电子或机械方式，包括复印、录制或通过任何信息存储和检索系统）复制、传播或存储于数据库或检索系统中，程序清单除外——这些清单可输入、存储于计算机系统并执行，但不得通过出版、影印、录制或任何电子及机械手段进行复制。
责任限制与担保免责声明
本书所载信息基于作者和出版者的认知，真实准确。作者已尽全力确保出版物的准确性，但出版者不对因本书任何信息引起的任何损失或损害承担责任。
本书提及的所有商标均视为其各自所有者的财产，但BPB Publications不保证此信息的准确性。
www.bpbonline.com
谨以本书献给
我挚爱的妻子：
波莉安娜
关于作者
奥塔维奥·桑塔纳是一位屡获殊荣的软件工程师和架构师，热衷于通过开源最佳实践赋能其他工程师，以构建高度可扩展和高效的软件。他是Java和开源生态系统的知名贡献者，其工作赢得了众多奖项和赞誉。奥塔维奥的爱好包括历史、经济、旅行和掌握多门语言，并极富幽默感。
关于审校者
卡琳娜·瓦雷拉的职业生涯专注于连接和支持企业软件的技术。她深入掌握广泛的技术栈、模式及最佳实践，尤其在Java企业解决方案领域。这一背景为她奠定了坚实基础，能够塑造从早期设计阶段到架构定义，再到云和容器基础设施平台上执行的关键任务解决方案。
她在应用平台方面的深厚专业知识，加上对开源的积极参与，是她十多年来在红帽和IBM参与关键企业解决方案的基础。
作为已出版作家和众多社区（例如SouJava协调员）的活跃贡献者，她的工作始终围绕构建健壮的技术和通过开放知识赋能开发者。
这一背景自然地为她最近作为Aletyx联合创始人的工作奠定了基础，该公司基于多年的实践经验和开源领导力，正在构建下一代智能自动化。
致谢
我要向我的家人、朋友和Java社区表示最深切的感谢，感谢他们的大力支持，使我能够投入时间创作本书。
我也感谢BPB Publications在本书出版过程中提供的指导和专业知识。本书的修订过程是一段漫长的旅程，期间有审校者、技术专家和编辑们的宝贵参与和合作。
最后，感谢所有对本书感兴趣的读者以及你们为使其成为现实所提供的支持。你们的鼓励无比珍贵。

发布于

Java智能体框架的繁荣是一种代码异味

停止构建编排框架，开始构建智能体。未来属于那些掌握生态系统的人，而不是那些被困在构建特定语言引擎中的人。

我需要坦白。我是一个框架狂热者。我的职业生涯建立在 Apache Camel 之上，我人生中的大部分成功都归功于企业集成模式的优雅。我懂。如果有一个社区值得获得诺贝尔框架奖，那就是 Java 社区。从早年在红帽公司到整个大数据生态系统，框架 15 年来一直是 JVM 世界的引擎。我们是抽象的大师。

因此，当智能体时代来临而 Java 在奋力追赶时，我的第一本能是原始的：构建一个框架。我甚至开始了一个，驱动力是这样一个想法："AI 智能体的 Apache Camel 在哪里？"

三个月前，可能只有一个严肃的 Java 智能体框架。现在，包括 Embabel 在内，已经有了三个。竞赛开始了。但目睹这场爆炸式增长，我不得不提出一个难题：框架本身是否正在成为一种反模式？我们是否在为自己创造负担，而不是专注于真正重要的事情：构建智能体？

最近 Java 智能体框架的繁荣并非一个健康、成熟生态系统的标志。它是一种症状。一种架构层面的代码坏味道，告诉我们我们的方法存在根本性问题。

我们最初为什么要构建框架？

让我们回顾一下。为什么像 Spring 和 Camel 这样的框架变得如此主流？原因清晰且合理：

  • 开发人员生产力： 我们当时淹没在样板代码中。框架将其抽象掉了。
  • 代码质量与治理： 它们提供了标准化的模式，防止每个开发人员重新发明轮子。
  • 可重用性： 它们为我们提供了经过实战检验的构造来构建，节省了大量的时间和精力。

目标是优化生产力、质量和治理。但这些是我们今天应该优化的相同参数吗？感觉我们像是在用 2010 年的方法解决 2025 年的问题，完全忽视了房间里的大象：AI 驱动的开发工具。

这头大象有个名字：Cursor（及其伙伴）

在我们忙于将 LangChain 移植到 Java 时，情况发生了变化：

Cursor 和 Copilot 生成样板代码的速度比你输入 import 语句还快。你正在构建的那个复杂的链式抽象？Cursor 三秒钟就能写出来。你正在标准化的那个工具注册模式？Copilot 已经知道五种变体。

但在这里，我们需要停下来问一个更根本的问题：你的最终用户实际需要什么？

你真正需要构建什么？

让我们具体点。我们大多数人面临两种情况：

  • 场景 1： 你在未来 12 个月内构建一个关键智能体。也许它是一个每天处理 10,000 次对话的客户服务智能体。或者一个需要理解你公司特定标准的代码审查智能体。或者一个绝不能对监管要求产生幻觉的合规智能体。
  • 场景 2： 你正在构建一个智能体平台。成百上千个智能体，每个都有不同的上下文、不同的领域、不同的需求。也许你在一家咨询公司，为多个客户构建智能体。或者你正在创建一个内部平台，不同团队可以在上面启动自己的智能体。你需要可重用、适应性强、可演进的东西。一种能让你快速创建新智能体，同时保持所有智能体一致性和质量的东西。

在这两种情况下，诚实地问自己：你的用户需要一个代码框架吗？

还是他们需要完全不同的东西？

重新定义框架

在放弃我的框架并实际交付智能体之后，我学到了：我们不需要消除框架。我们需要重新定义在 AI 时代框架实际意味着什么。

  • 旧框架定义： 一种可重用的代码抽象，提供结构并处理横切关注点。你导入并在其之上构建的东西。
  • 新框架定义： 构建智能体的完整环境，一组协同工作的相互依赖的层，其中代码层只是更大拼图的一部分。

以下是现代智能体框架中真正重要的层次：

第 1 层：语言本身

Java（或你选择的语言）及其构造、类型和模式。不包装在抽象中，直接使用。语言已经是你的逻辑结构框架。你不需要在 Java 之上再加一个代码框架。Java 本身就是框架。

第 2 层：模型

一个真正好的大语言模型：GPT-5、Claude、Gemini、Grok。这不仅仅是你调用的 API。它是你技术栈的核心组件。模型的能力直接决定了你能构建什么。像选择编程语言一样仔细地选择它。

第 3 层：开发人员生产力工具

Cursor、Copilot 以及下一代 AI 驱动的开发工具。这些不是可选的。它们是关键基础设施。你的框架应设计成与这些工具无缝协作。如果 Cursor 不能轻松地按照你的模式生成代码，那么你的模式是错误的，或者你可能需要很好地描述你的模式。

第 4 层：提示词包与指南

你经过版本控制、测试、治理的提示词。你的组织语音。你的领域知识。你的合规规则。这是你的业务逻辑存在的地方——不在代码中，而在精心策划的上下文和指令中。将这些视为你的依赖构件，就像 JAR 包，但用于智能体行为。

第 5 层：生态系统 API

对新兴的专业化平台及其 API 的上下文感知。用于知识检索的向量数据库。上下文存储和内存管理系统，如 Zep 或 Cognee。工具执行平台，如 Arcade。用于智能体监控的可观测性平台，如 Langfuse。提示词管理和版本控制工具。这些大多暴露 REST API 或标准协议，大多提供 LLM.txt 用于上下文导入。你的框架需要知道这些存在，并知道如何连接到它们。

第 6 层：架构与设计模式

作为指南和模式捕获的架构思维。关于这些层如何在不同用例中组合在一起的可重用蓝图。不是代码抽象——关于路由逻辑、版本控制策略、部署模式和生态系统集成的文档化知识，这些知识成为你组织上下文的一部分。

想想看。当你构建那个关键的客户服务智能体时，真正决定其成功的是什么？

  • 调用 LLM 的 Java 代码吗？（那是 20 行代码，Cursor 写的）
  • 复杂的链式编排吗？（标准控制流）
  • 重试逻辑和错误处理吗？（Java 已经有这方面的模式）

还是：

  • 你选择的模型以及它处理你领域的能力
  • 教导它你的升级规则和语气的提示词
  • 让你能快速迭代这些提示词的工具
  • 与像 Arcade（工具）和 Zep（内存）这样的平台的集成
  • 让你能够对变更进行版本控制、测试和部署的架构
  • 让你能在多个智能体中重用这种方法的设计模式

那就是你的框架。所有六层，协同工作。

实践中的框架

让我向你展示在构建智能体时的实际示例：

第 4 层（提示词包） 是版本化的构件，不是你代码中的字符串：

prompts/
  customer-service/
    v1.2/
      system-prompt.md
      escalation-rules.md
      tone-guidelines.md
      product-context.md
      examples/
        refund-scenarios.yaml
        technical-issues.yaml

第 5 层（生态系统 API） 配置在你的环境中：
你的生态系统上下文嵌入在指南中：

# 生态系统集成指南

## 工具发现
- 调用 Arcade API 列出可用工具: GET /tools
- 参考: 查看 Arcade LLM.txt 位于 https://docs.arcade.dev/llms.txt

## 内存管理
- Zep 会话 API: https://api.getzep.com/v2/sessions/{session_id}
- 参考: 查看 Zep API 文档位于 https://docs.getzep.com

## 基础设施与存储
- 用于提示词构件的对象存储: S3, GCS, 或 Azure Blob
- 用于长时间运行工作流的状态持久化

第 1 层（Java） 提供结构，干净简单：

public class CustomerServiceAgent {
    private final Model model;
    private final PromptPack prompts;
    private final ArcadeClient tools;
    private final ZepMemory memory;

    public Response handle(CustomerQuery query) {
        // 检索会话内存
        var history = memory.getSession(query.sessionId());

        // 从 Arcade 获取可用工具
        var availableTools = tools.listTools();

        // 使用上下文渲染提示词
        var context = prompts.render("main", query, history, availableTools);

        return model.complete(context);
    }
}

第 3 层（Cursor） 在几秒钟内生成这段代码。你专注于架构。

第 6 层（架构） 指南：

# 智能体架构指南

## 工作流路由
- 为多节点智能体工作流设计路由逻辑
  - 分类节点 → 路由到专家节点（支持、销售、技术）
  - 复杂性分析 → 路由到适当的模型层级（GPT-4o vs GPT-3.5）
  - 工具选择节点 → 根据用户意图路由到工具执行节点
- 通过 Arcade 网关路由工具执行：集中认证、速率限制、工具发现
- 提示词版本的 A/B 路由：10% 到 v2.0，90% 到 v1.5，监控质量

## 速率限制与节流
- 每用户令牌预算：10K 令牌/天（免费），100K（付费）
- 队列管理：最大 100 个并发请求，溢出到 SQS...
..
..

为什么这个框架能扩展

  • 对于一个关键智能体： 选择你的模型（第 2 层），编写清晰的代码（第 1 层），用 Cursor 迭代（第 3 层），优化提示词（第 4 层），集成生态系统 API（第 5 层），遵循架构模式（第 6 层）。
  • 对于一千个智能体： 相同的模型，相同的架构模式，相同的生态系统 API，但每个智能体都有自己的提示词包。Cursor 生成样板代码。你的语言提供结构。生态系统处理难题。

美妙之处何在？各层协同工作。Cursor 生成代码是因为模式简单。提示词是独立版本控制的。集成使用 REST API。架构无需抽象即可实现重用。

不需要编排框架。这就是框架。

引擎与 SDK 的问题

让我澄清一下：我并不是说所有框架都应该消失。我对 LangChain、LangGraph、Mastra、CrewAI、Autogen 等团队所构建的东西怀有极大的敬意。但我们需要理解一个在急于将所有东西移植到 Java 的过程中被忽视的关键区别。

不要混淆引擎和 SDK。

我的意思是：我迫不及待地想用 Java 开发完整的智能体。我热爱 Java。但我不想仅仅因为我想用 Java 开发智能体就要一个 Java 引擎。

考虑这些例子：

  • LangChain4J？ 作为连接更广泛的 LangChain 生态系统的 SDK，这是一个很好的开始。你用 Java 编写，但你正在利用一个经过验证的引擎。
  • 带有 Java SDK 的 Crew AI？ 完美。在 Python 中掌握编排模式，然后给我一个 Java 接口来使用它们。
  • 支持多语言的 Mastra？ 正是正确的方向。构建一次引擎，为每种语言提供 SDK。
  • 为使用 Go 构建的 Not7 添加 Java SDK 或任何语言 SDK？

这里的模式是？用你喜欢的语言开发，而无需用该语言重建整个引擎。

编排层正在变薄

这就是为什么我认为即使是 SDK 方法也可能是暂时的，或者至少变得非常精简的原因：

  • 一方面： 模型正变得 dramatically 更好。GPT-5、Claude 4.5、Gemini 2.5 Pro、Grok 的推理能力使得复杂的编排模式过时了。它们可以用简单的提示词处理多步骤工作流，而这在六个月前需要复杂的链。
  • 另一方面： 真正的工程问题正在由专业平台解决。以 Arcade 为例：工具发现、认证、大规模执行、处理速率限制、管理工具版本。这才是艰难的工程工作所在。工具管理不再是编排问题；它是在平台层解决的基础设施问题。
  • 在中间： 编排框架正被挤压得越来越薄。

当你的模型能够推理工作流，并且平台处理复杂的工程问题（工具、内存、上下文）时，编排还剩下什么？

答案是：非常少。这就是为什么工程重点需要从编排转向更广泛的智能体开发挑战——提示词管理、生态系统集成、工具决策可审计性、成本优化。真正的问题已不在编排之中。

新现实：AI 原生框架

代码坏味道不仅仅是我们构建了太多框架。而是我们正在为一个不复存在的世界构建框架。以下是 2025 年构建框架实际意味着什么：

方面 过去的框架思维模式 (2005-2024) 下一代框架思维模式 (2025+)
定义 需要导入的代码库 跨越6个层级的完整环境
业务逻辑 位于代码抽象中 位于版本化提示词与指南中
关键构件 JAR 文件、软件包 提示词、上下文、API 知识
可重用性 代码继承与组合 架构模式与蓝图
开发工具 用于编写代码的 IDE 用于生成代码的 AI 工具（如 Cursor）
生态系统 自包含、单体式 集成专业化平台
样板代码 由框架抽象处理 由 AI 在几秒内生成
你导入/使用什么 Spring、Camel、框架 JAR 包 无需导入——你只需组合这些层级
  1. 接受 AI 驱动的开发现实 每个构建智能体的开发人员都将使用 Cursor、Copilot 或类似工具。这不是趋势——这是新的基线。设计你的框架以与 AI 代码生成无缝协作，而不是背道而驰。如果 Cursor 无法理解你的模式，那你的模式就是错的。
  2. 你的框架是纯文本英语，而不仅仅是代码 你的框架最关键部分将是精心设计的提示词、清晰的指南和结构化的上下文——而不是聪明的抽象。这些是你的版本化构件。这些决定了智能体行为。像对待代码一样严格对待它们。
  3. 当你需要 SDK 时，不要重新发明引擎 是的，Java SDK 至关重要。但你不需要仅仅为了用 Java 编写智能体就重建整个编排引擎。生态系统已经有平台在解决难题：内存（Zep, Mem0）、工具（MCPs, Arcade）、向量（Weaviate, Pinecone, Qdrant）、可观测性等。集成，不要重建。
  4. 框架仍然至关重要——但不是为了编排 如果你正在解决真正的问题——提示词版本控制、决策可审计性、生态系统集成模式、成本优化——那就构建这些。但编排？生态系统已经向前发展了。内存、工具、上下文、可观测性正由专业平台解决。将你的创新重点放在其他地方。
  5. 相信你的语言 如果你觉得你选择的语言中缺少一个框架，请退后一步。现代语言——Java、Python、TypeScript、Go——非常强大。凭借它们的最新特性加上 AI 代码生成工具，你可以用干净、简单的代码构建复杂的智能体。你的语言不是限制——试图用不必要的抽象包装它才是。

未来的框架不是你导入的代码库。它是对六个相互依赖层的掌握：你的语言、你的模型、你的开发工具、你的提示词、你的生态系统集成和你的架构。

也许我们不需要另一个智能体框架。也许我们所需要的只是一个智能体，一个能用你选择的语言创建智能体的智能体。一个开源的就更好了。

【注】本文译自：Java’s Agentic Framework Boom is a Code Smell

发布于

Netflix系统架构解析

Netflix系统架构解析

Netflix架构旨在高效可靠地同时为数百万用户提供内容。以下是其特性和组件的详细分析。

是否曾好奇Netflix如何让您目不转睛地享受无中断的流畅播放体验？幕后功臣正是Netflix架构，它负责提供吸引全球观众的无缝流媒体体验。Netflix的系统架构强调了决定未来内容形态的重要性。让我们一起探索Netflix流媒体宇宙的幕后故事！
Netflix已成为娱乐、追剧和尖端流媒体服务的代名词。其迅速崛起可归因于庞大的内容库、全球覆盖以及弹性创新的架构。
从1997年的DVD租赁服务发展为全球流媒体巨头，Netflix始终运用前沿技术革新着媒体消费方式。
Netflix架构旨在高效可靠地同时为数百万用户提供内容。鉴于其在190多个国家拥有超过2亿会员，基础设施的可扩展性至关重要。
让我们深入探究Netflix架构的复杂性，揭示其如何持续塑造我们享受喜爱节目的方式。

理解Netflix系统架构的重要性

理解Netflix系统架构至关重要，原因包括：
首先，它揭示了Netflix如何为全球数百万用户提供无瑕疵的流媒体体验。通过探索架构细节，我们能更好地理解其成功背后的技术与策略。
此外，其他行业可将Netflix设计作为开发可扩展、可靠且高效系统的蓝图。其设计原则和最佳实践为构建复杂分布式系统提供了重要经验。
理解Netflix架构还能让我们认识到推动数字媒体消费发展的持续创新。

理解系统设计需求

系统设计对开发复杂软件或技术基础设施至关重要。这些规范是构建整个系统的基础，驱动决策并塑造最终产品。那么系统设计的先决条件是什么？为何如此重要？让我们进行探讨。

功能性需求

功能性需求规定了系统必须包含的功能和能力。这些规范概述系统主要目标，并详述各部件如何交互。以Netflix为例的流媒体平台功能性需求包括但不限于：

  1. 账户创建: 用户应能轻松创建账户，提供注册所需信息。
  2. 用户登录: 注册用户应能通过认证凭证安全登录。
  3. 内容推荐: 平台应根据用户偏好和观看历史提供个性化建议。
  4. 视频播放: 用户应能无缝播放视频，支持播放控制功能。

非功能性需求

非功能性需求定义系统在不同场景下的行为，确保满足特定质量要求。涵盖性能、可扩展性、可靠性、安全性和合规性等方面。以Netflix为例包括但不限于：

  1. 性能需求: 高负载时保持低延迟和高吞吐量。
  2. 合规需求: 遵守数据保护法规标准。
  3. 扩展性需求: 基础设施需支持用户增长而不影响性能。
  4. 安全需求: 实施强认证和加密防止未授权访问。
  5. 可靠性需求: 包含故障转移方法并保证高正常运行时间。

Netflix架构：拥抱云原生

2008年8月因数据库损坏遭遇重大挫折后，Netflix得出关键结论：必须摆脱单点故障，转向高可靠、水平可扩展的云解决方案。Netflix选择AWS作为云供应商，2015年将多数服务迁移至云端。经过七年努力，2016年1月初完成云迁移，关闭了最后的数据中心组件。
上云并非易事。Netflix采用云原生策略，彻底改革运营模式和技术栈：采用NoSQL数据库、反规范化数据模型、从单体应用转向数百个微服务。文化变革也不可或缺，如采用DevOps流程、持续交付和自助式工程环境。尽管困难重重，此转型使Netflix成为云原生企业，为在线娱乐领域的未来扩展和创新奠定基础。

Netflix架构三要素

由客户端、后端和内容分发网络(CDN)构成的强大架构三要素，共同保障无瑕疵用户体验。面对全球数百万观众，每个组件对内容交付都至关重要。

客户端

客户端架构是Netflix体验的核心，涵盖用户访问的各种设备(电脑、智能电视、智能手机)。Netflix混合使用Web界面和原生应用确保跨平台一致体验。无论设备类型，这些客户端管理播放控制、用户交互与界面渲染，提供统一体验。得益于响应式优化，用户可轻松浏览内容库并享受连续播放。

后端架构

后端架构是幕后运营的支柱。用户账户管理、内容目录、推荐算法、计费系统等由复杂的服务器、数据库和微服务网络处理。
后端不仅处理用户数据与内容交付，还运用大数据分析和机器学习优化内容交付与个性化推荐，提升用户满意度。
Netflix后端架构历经重大演变：2007年迁移至云基础设施，2018年采用Spring Boot作为主要Java框架。结合AWS的可扩展性和可靠性，Ribbon、Eureka和Hystrix等专有技术有效协调后端运营。

内容分发网络(CDN)

CDN完善架构三角。Netflix运营名为Open Connect的CDN，通过战略部署的全球服务器网络，以最高可靠性和最小延迟交付内容。
通过在靠近用户的站点缓存内容，减少缓冲并确保流畅播放。即使在高峰期，通过全球服务器分发内容减少拥塞并最大化带宽利用率。这种去中心化方式提升全球观看体验，降低缓冲时间并提高流媒体质量。

客户端组件

Web界面

近年Netflix Web界面经历重大转型，从Silverlight转向HTML5流式传输视频内容。此举消除了浏览器插件需求，简化用户体验。自采用HTML5后，提升了对Chrome、Safari、Firefox等浏览器的兼容性。
Netflix对HTML5的应用不仅限于基础播放，还借此支持行业标准与技术进步。

移动应用

通过iOS和Android应用将流媒体体验延伸至移动用户。结合原生开发与平台优化，为各类移动设备提供流畅界面。
凭借个性化推荐、无缝播放和离线下载等功能，满足移动观众需求。用户可随时随地观看喜爱的内容，Netflix通过频繁升级提供引人入胜的移动体验。

智能电视应用

电视应用基于复杂架构，包含Gibbon渲染层、动态更新的JavaScript应用和原生SDK。通过定制版React-Gibbon确保跨电视平台的流畅UI渲染与响应。
性能优化聚焦每秒帧数与输入响应等指标，通过减少属性迭代等方法提升渲染效率，样式优化与自定义组件开发进一步优化性能。

重塑播放体验：现代化之旅

过去十年Netflix彻底改变了数字媒体消费方式。尽管持续推出创新功能，但自2013年以来播放界面的视觉设计与用户控制鲜有变化。认识到需要更新后，Web UI团队着手重新设计。
团队聚焦三大画布：播放前、视频播放和播放后，目标是提升客户满意度。通过React.js和Redux等技术加速开发与提升性能，革新了播放界面。

后端基础设施

内容分发网络(CDN)

Netflix基础设施依赖Open Connect CDN，轻松向全球数百万观众交付内容。全球分布的CDN对确保各地高质量流媒体至关重要。
通过名为OCA的服务器战略部署于ISP和用户附近，在高峰期降低延迟并保障性能。通过在ISP网络预置内容，最大化带宽利用率并减少对骨干网络的依赖。
可扩展性是CDN的核心特性。全球约1000个地点部署OCA(包括偏远地区)，满足各地增长需求。
向合格ISP提供OCA，使其直接从自身网络提供内容，既提升质量又降低ISP成本，建立双赢关系。

视频处理转型：微服务革命

通过实施微服务改造视频处理流水线，实现无与伦比的可扩展性和灵活性。从单体平台转向微服务平台开启了敏捷性和功能开发速度的新纪元。
视频处理流程的每一步由独立微服务代表，实现简化编排与解耦功能。从视频检测到编码，这些服务共同产出优质视频资产。微服务通过快速迭代适应业务需求变化，取得显著成效。

Open Connect播放流程

全球客户能够享受丝滑无暇的观看体验得益于Netflix Open Connect 的播放流程。其运作方式如下：

  1. 健康状态报告: 开放连接设备(OCAs)定期向亚马逊云服务(AWS)中的缓存控制服务汇报其学习到的路由信息、内容可用性及整体运行状况。
  2. 用户请求: 用户通过客户端设备上托管在AWS的Netflix应用程序请求播放电视剧或电影。
  3. 授权与文件选择: 在验证用户授权和许可后，AWS播放应用程序服务会精确选择处理播放请求所需的文件。
  4. 导向服务: AWS导向服务根据缓存控制服务保存的数据，选择用于提供文件的OCA设备。播放应用程序服务从导向服务获取这些OCA设备信息并构建其URL地址。
  5. 内容传输: 播放应用程序服务将相关OCA的URL发送至客户端设备。当请求的文件通过HTTP/HTTPS协议传输至客户端时，选定的OCA设备即开始提供服务。

下方图示展示了完整的播放流程：

数据库架构

利用Amazon S3实现无缝媒体存储

Netflix在2022年4月21日AWS服务中断期间的表现，充分证明了其云基础设施的价值，特别是对Amazon S3数据存储服务的依赖。通过整合SimpleDB、S3和Cassandra等服务，Netflix构建了能够承受此类中断的健壮系统。
作为基础设施的核心支柱，Netflix采用Amazon S3（简单存储服务）存储海量影视内容与原创作品。为服务全球数亿用户，平台需要管理PB级数据，而S3提供的可扩展、高可靠且易访问的存储特性成为理想选择。
内容库持续扩张时，S3使Netflix无需担忧硬件扩容或复杂存储架构维护，完美契合其"不牺牲用户体验"的扩展需求。

拥抱NoSQL实现弹性扩展

面对分布式架构的结构化存储需求，Netflix在发现传统关系型数据库的局限性后，全面转向NoSQL分布式数据库。技术栈中Cassandra, Hadoop/HBase, 和SimpleDB三大核心方案各具优势。

Amazon SimpleDB

迁移至AWS云时，SimpleDB凭借强大的查询能力、跨可用区自动复制和高持久性成为首选。其托管特性有效降低了运维成本，符合Netflix将非核心业务外包给云服务商的策略。

Apache HBase

作为Hadoop生态的高性能解决方案，HBase通过动态分区策略实现负载均衡与集群扩展，完美应对Netflix的数据增长挑战。分布式计数器、范围查询和数据压缩等功能，进一步强化了其一致性架构的健壮性。

Apache Cassandra

这款开源NoSQL数据库以性能、弹性和灵活性见长。动态集群扩展能力满足Netflix无限扩容需求，自适应一致性机制与灵活数据模型使其成为跨区域部署、避免单点故障的理想选择。
虽然需要面对学习曲线和运维成本，但NoSQL在可扩展性、可用性和性能方面的优势，使其成为Netflix长期云战略的关键支柱。

计费系统中的MySQL实践

Netflix计费系统作为向AWS云原生架构全面迁移的一部分经历了重大转型。由于Netflix运营高度依赖计费系统，此次迁移被谨慎处理以确保对会员体验的影响最小化，同时严格遵守严格的财务标准。
跟踪计费周期、监控支付状态以及向财务系统提供报告数据只是Netflix计费基础设施处理的众多任务中的几项。计费工程团队管理着一个包含批处理任务、API、与其他服务的连接器以及数据管理的复杂生态系统来实现这些功能。
数据库技术的选择是迁移过程中最重要的决策之一。由于支付处理需要可扩展性和ACID事务支持，MySQL被选为数据库解决方案。
构建健壮的工具链、优化代码和清理不必要数据都是迁移过程的一部分，以适应新的云架构。在转移现有会员数据前，团队使用代理和重定向器处理流量重定向，并采用干净数据集进行了全面测试流程。
将计费系统迁移至AWS上的MySQL是个复杂过程，需要周密规划、系统实施以及持续测试和迭代。尽管存在困难，迁移最终顺利完成，使Netflix能够利用AWS云服务的可扩展性和可靠性来支持其计费系统。
总之，将Netflix计费系统切换至AWS上的MySQL涉及大量工程工作并产生广泛影响。Netflix的系统架构已更新其计费系统，并采用基于云的解决方案为数字领域的未来发展做好准备。
以下是Netflix迁移后的架构：

Netflix架构中的内容处理流水线

Netflix内容处理流水线是处理内容合作伙伴提供的数字资产的系统化方法。主要包含三个阶段：内容摄取、转码和封装。

内容摄取

在摄取阶段，音频、定时文本或视频等源文件会经过严格的准确性和合规性检查。这些验证包括：语义信号域检查、文件格式验证、压缩码流可解码性验证、符合Netflix交付标准以及数据传输完整性检查。

转码与封装

通过摄取阶段的源文件会进行转码处理，生成输出基本流。随后这些流会被加密并封装至可分发的流式容器中。

通过Netflix金丝雀模型确保无缝流媒体体验

由于客户端应用是用户与品牌互动的主要方式，它们必须保持卓越品质。Netflix系统架构投入大量资源确保对更新版本进行全面评估。然而，由于Netflix需要在数千种设备上运行，并依赖数百个独立部署的微服务，全面内部测试变得困难。因此，必须依靠更新过程中获取的可靠现场数据来支持发布决策。
为加速客户端应用更新评估，Netflix系统架构组建了专门团队从现场挖掘健康信号。这项系统投资提高了开发速度，改善了应用质量和开发流程。

  1. 客户端应用: Netflix通过两种方式更新客户端应用：直接下载和应用商店部署。直接下载提高了分发控制力。
  2. 部署策略: 虽然定期增量发布的优势众所周知，但软件更新仍存在挑战。由于每个用户设备都以流形式传输数据，高效信号采样至关重要。Netflix采用定制部署策略应对各类设备和复杂微服务的独特挑战。策略因客户端类型而异（如智能电视与移动应用）。新版本通过分阶段发布逐步推出，提供快速故障处理和智能后端服务扩展。发布过程中监控客户端错误率和采用率可确保部署的一致性和有效性。
  3. 分阶段发布: 为降低风险并合理扩展后端服务，分阶段发布需要逐步部署新版本。
  4. AB测试/客户端金丝雀: Netflix采用强化的A/B测试变体"客户端金丝雀"，通过完整应用测试确保数小时内完成及时更新。
  5. 编排: 编排减少了频繁部署和分析的工作量，有效管理A/B测试和客户端金丝雀。

总之，得益于Netflix采用客户端金丝雀模型，数百万用户能享受无瑕疵的流媒体体验，该模型确保了应用的频繁更新。

Netflix架构图示

Netflix系统架构是一个复杂生态系统：后端服务采用Python和Java（Spring Boot），数据处理和实时事件流使用Apache Kafka和Flink。前端采用Redux、React.js和HTML5提供沉浸式用户体验。多种数据库（包括Cassandra、HBase、SimpleDB、MySQL和Amazon S3）提供实时分析并处理海量媒体内容。Jenkins和Spinnaker实现持续集成和部署，AWS为整个基础设施提供可扩展性、可靠性和全球覆盖能力。
这些技术仅占Netflix庞大技术栈的一小部分，体现了其为全球观众提供完美娱乐体验的决心。

Netflix架构总结

Netflix系统架构彻底改变了娱乐行业。从DVD租赁服务发展为全球流媒体巨头，其技术基础设施是成功的关键。
依托AWS支持的Netflix架构确保全球用户的无中断流媒体体验，通过客户端、后端和内容分发网络(CDN)实现跨设备的无瑕疵内容传输。
HTML5的创新应用和个性化推荐提升了用户体验。
尽管面临挑战，向云原生架构的转型使Netflix更加强大。通过采用微服务、NoSQL数据库和云解决方案，Netflix在快速发展的在线娱乐领域为未来创新做好准备。任何技术企业都能从理解Netflix系统中获益。
简而言之，Netflix系统架构不仅关乎技术，更旨在改变我们的媒体消费方式。当观众追剧时，这套架构在幕后确保一切顺畅运行，提升每个人的娱乐享受。

【注】本文译自： A Look Into Netflix System Architecture