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

目录

1. 理解领域驱动设计
引言
结构
学习目标
领域驱动设计的重要性
连接业务目标与技术实现
核心概念与方法论
DDD的战略层面
DDD的战术层面
本章小结
要点总结
选择题
    答案
参考文献
2. 战略DDD概念
引言
结构
学习目标
领域与子域
    EcoTrack物流示例场景
理解限界上下文
上下文映射技术
业务战略与软件设计的对齐
本章小结
要点总结
选择题
    答案
参考文献
3. 战术DDD实现
引言
结构
技术要求
学习目标
实体与值对象
    实体的陷阱
    建造者与领域特定语言
    值对象
聚合与聚合根
服务及其角色
实现仓储
本章小结
要点总结
选择题
    答案
参考文献
4. 测试与验证DDD应用
引言
结构
技术要求
学习目标
DDD测试入门
单元测试DDD组件
    定义领域组件
    使用测试验证预期行为
    增强测试
使用ArchUnit进行架构验证
本章小结
要点总结
选择题
答案
参考文献
5. 微服务、单体与分布式系统中的DDD
引言
结构
技术要求
学习目标
单体架构中的DDD
    创建领域层与组织包结构
    创建应用层
    创建控制器层
    创建基础设施层
微服务架构中的DDD
微服务的必要性
在分布式系统中应用DDD
重构遗留代码以遵循DDD原则
本章小结
要点总结
选择题
    答案
参考文献
6. 将DDD与整洁架构集成
引言
结构
技术要求
学习目标
整洁架构概述
DDD与整洁架构的结合
    使用整洁架构与DDD创建清晰边界
    在核心应用与外部系统间搭建桥梁
构建可维护的代码结构
    每种方法的使用与组合
本章小结
要点总结
选择题
答案
参考文献
7. DDD与数据建模
引言
结构
技术要求
学习目标
DDD在数据建模中的原则
SQL数据库中的数据建模
    Jakarta Persistence实战
NoSQL数据库中的数据建模
本章小结
要点总结
选择题
答案
8. 使用Jakarta EE的企业级Java开发
引言
结构
技术要求
学习目标
使用Jakarta EE应用DDD
利用Jakarta Data实现更好的封装
将DDD集成到企业级Java应用中
本章小结
要点总结
选择题
    答案
9. 使用Spring的企业级Java开发
引言
结构
技术要求
学习目标
Spring框架与DDD概述
使用Spring Boot应用DDD
    创建并设置新的Spring Boot项目
    定义核心领域实体
    构建仓库与服务
    通过REST端点暴露服务
    完善错误处理
    通过单元测试确保代码行为
本章小结
要点总结
选择题
    答案
10. Eclipse MicroProfile与领域驱动设计
引言
结构
技术要求
学习目标
理解Eclipse MicroProfile及其目标
    澄清Jakarta EE与MicroProfile的相似之处
    Eclipse MicroProfile架构与规范
将Eclipse MicroProfile与DDD集成
微服务实战示例
本章小结
要点总结
选择题
答案
参考文献
11. Quarkus与领域驱动设计
引言
结构
技术要求
学习目标
Quarkus、Jakarta EE与MicroProfile的集成
Quarkus实战
    创建并设置新项目
    配置数据库集成
    Panache实体与资源代码生成
    验证应用行为
    使用Panache的Active Record模式
    使用Panache的仓库模式
    从DDD视角使用Panache
本章小结
要点总结
选择题
    答案
参考文献
12. DDD的代码设计与最佳实践
引言
结构
学习目标
贫血模型与富血模型
DDD中的流式API与建造者模式
DDD中的异常处理与日志记录
    定义异常层次结构
    创建可追踪的异常信息
    安全地处理异常与日志
长期代码质量与可持续性
本章小结
要点总结
选择题
    答案
参考文献
13. 最终考量
引言
结构
技术要求
学习目标
领域叙事法介绍
    领域叙事法的目的与益处
    领域叙事法与敏捷头脑风暴的区别
    探索领域叙事法
延伸阅读与持续探索
本章小结
要点总结
参考文献
索引

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

前言

很长一段时间以来,我在多次会议上谈论我最喜欢的话题之一:软件设计和DDD。像往常一样,我首先询问有多少人听说过DDD?答案是异口同声的肯定。但当我提出第二个问题时,情况就变了:你们中有多少人正确地使用了DDD?答案通常是没有人或只有少数人。那么,为什么有大量的人了解DDD,却只有极少数例外能正确应用它呢?为了解决这个问题,我写了这本书来帮助你。
许多团队在现实项目中难以有效实施DDD。问题的根源相当简单:尽管这些模式已广为人知,但它们的目的常常被误解或忽视。本书旨在弥合这一差距,不仅解释DDD是什么,还通过从背后的原理入手,指导如何有效应用它。
本书首先探讨DDD存在的基础原因。通过理解其战略原则,开发者可以避免常见且往往代价高昂的实施错误。许多关于DDD的书籍假设读者已经确信其价值;本书则退后一步,建立这种基础理解,融合了其他作者的见解,并辅以实际示例和现实经验。本书避免教条主义,将既定理论与现代用例相结合,帮助你做出更适合特定情境的更好设计决策。
为了指导你完成这段旅程,本书分为三个部分。第一部分奠定了DDD的战略基础,强调了理解领域、与业务专家协作以及使用限界上下文和上下文映射等概念来组织系统的重要性。这部分特意放在开头,因为掌握战略DDD对于防止后续的错位和过度工程至关重要。
一旦基础奠定,第二部分就转向DDD的战术方面,即设计与实现的交汇处。你将学习如何建模聚合、封装业务规则,以及如何在不同架构风格(包括单体架构、微服务和分布式系统)中应用DDD。本部分还设有一章专注于测试和验证,帮助你长期维护模型的完整性和表现力。
本书的最后一部分通过研究如何使用 Jakarta EE、Spring、Eclipse MicroProfile 和 Quarkus 等工具将 DDD 集成到现实世界企业环境中,综合了所有概念。它还涉及高级设计实践,包括代码级决策和要避免的反模式。本书最后反思了领域叙事——一种旨在帮助团队建立共同理解并弥合业务与技术之间差距的技术。
第1章:理解领域驱动设计
旅程从介绍领域驱动设计本身开始——它的历史、动机以及它旨在解决的基本问题:业务需求与软件交付之间的脱节。本章通过展示DDD如何鼓励技术团队和业务团队之间的沟通,以及它如何帮助创建既富有表现力又与核心领域保持一致的模型,来奠定基础。
第2章:战略DDD概念
本章通过探索战略DDD概念来加深理解。它介绍了最容易被遗忘的部分和DDD的陷阱,即战略层面。事实上,这通常是DDD中最大的错误所在。我们将探讨几种战略DDD概念,例如限界上下文、上下文映射等。这些工具共同帮助团队管理复杂性,创建更清晰、更有目的性的系统。
第3章:战术DDD实现
在本章中,我们进入战术实现。这里,DDD的构建块——实体、值对象、聚合、服务和仓库——不仅被解释,还通过实际的Java代码进行说明。本章将前面部分的抽象概念与具体的编程实践联系起来,展示了如何在将领域逻辑变为现实的同时,使其与基础设施关注点解耦。
第4章:测试与验证DDD应用
本章顺理成章地解决了如何通过测试来验证和保护领域逻辑的问题。它超越了单元测试,包括使用 ArchUnit 和 jMolecules 等工具进行集成测试和架构验证。它还展示了在DDD背景下进行测试如何将领域模型强化为活的文档和有关业务行为的真相来源。
第5章:微服务、单体与分布式系统中的DDD
DDD与软件架构无关;实际上,它可以应用于多种架构结构,例如经典且直接的单体架构和分布式系统。本章涵盖了几种架构选择,并解释了如何在DDD中使用它们。
第6章:将DDD与整洁架构集成
本章探讨了DDD与整洁架构之间的协同作用。它没有将它们视为独立的学科,而是展示了它们如何通过强化关注点分离和确保领域逻辑保持在核心位置来相互补充。你将学习如何构建应用程序以提升灵活性、可维护性以及领域与外部系统之间的清晰边界。
第7章:DDD与数据建模
数据库是现代应用的核心,我们需要考虑在SQL和NoSQL数据库上进行建模,并进一步将它们与DDD结合。处理与领域相关的数据建模是本章的核心组成部分和范围,它考察了在两种不同范式(一种来自数据库,一种来自应用)上工作的影响。
第8章:使用Jakarta EE的企业级Java
本章将讨论带入企业级Java,重点关注Jakarta EE。它介绍了包括Jakarta Data在内的最新Jakarta规范如何支持DDD友好的设计。
第9章:使用Spring的企业级Java
本章介绍了一个如何在Spring平台上使用DDD的实践示例,重点关注最流行的组件,如Spring Data和Spring Boot,以及应用于DDD的代码结构。
第10章:Eclipse MicroProfile与领域驱动设计
本章介绍Eclipse MicroProfile,并解释它如何赋能云原生DDD应用。借助配置、容错和可观测性等特性,MicroProfile帮助开发者构建既具有弹性又以业务逻辑为中心的系统。本章逐步讲解如何在动态环境中保持应用程序的模块化和表现力。
第11章:Quarkus与领域驱动设计
在本章中,重点转向Quarkus——一个为高性能和开发效率而设计的现代Java框架。本章解释了如何使用Quarkus扩展、响应式编程和高效的依赖注入,在轻量级、容器友好的应用中实现DDD,同时不牺牲设计质量。
第12章:DDD的代码设计与最佳实践
本章专注于设计质量本身。它讨论了维护富有表现力和可持续代码库的最佳实践,包括如何避免贫血领域模型、何时应用建造者模式或流式API,以及如何为长期可读性和协作构建代码。它还提供了负责任地重构和发展领域模型的实用建议。
第13章:最终考量
本章总结了全书,并解释了如何提取战略领域并开始使用最古老的技术——叙事法来实现它。这种技术通过以叙事形式可视化地建模过程,使开发者和领域专家更紧密地保持一致。通过使用叙事法,团队可以发现隐藏的假设、澄清术语,并确保所构建的软件真正代表其所服务的业务。
贯穿本书,我们的目标是揭开DDD的神秘面纱,并为你提供在现实世界的Java项目中应用它的工具和思维方式。无论你是从头开始设计系统,还是重构遗留代码库,每一章都旨在帮助你创建能够表达领域语言并交付真正价值的软件。
代码包与彩色图片
请点击以下链接下载本书的代码包与彩色图片
https://rebrand.ly/c46852
本书的代码包也托管在GitHub上:https://github.com/bpbpublications/Domain-driven-Design-with-Java。如果代码有更新,将在现有的GitHub仓库中更新
我们在 https://github.com/bpbpublications 提供了来自我们丰富的书籍和视频目录的代码包。请查看!
勘误表
BPB Publications为我们的工作感到无比自豪,并遵循最佳实践以确保内容的准确性,为我们的订阅者提供愉悦的阅读体验。我们的读者是我们的镜子,我们利用他们的反馈来反思并改进出版过程中可能发生的人为错误。为了让我们保持质量并帮助联系到因任何未预见错误而遇到困难的读者,请写信至:errata@bpbonline.com
BPB Publications家族非常感谢您的支持、建议和反馈。
在 www.bpbonline.com,您还可以阅读免费技术文章集,注册各种免费时事通讯,并享受BPB书籍和电子书的独家折扣和优惠。您可以在下面查看我们的社交媒体账号:
盗版
如果您在互联网上以任何形式遇到我们作品的非法复制品,若能提供其地址或网站名称,我们将不胜感激。请通过 business@bpbonline.com 联系我们,并附上材料链接。
如果您有兴趣成为作者
如果您是某个领域的专家,并且有兴趣撰写或贡献一本书,请访问 www.bpbonline.com。我们已经与成千上万的开发人员和技术专业人士合作,就像您一样,帮助他们与全球技术社区分享他们的见解。您可以提交一般申请,申请我们正在招募作者的特定热门主题,或者提交您自己的想法。
评论
请留下评论。一旦您阅读并使用过本书,为什么不在您购买它的网站上留下评论呢?潜在的读者就可以看到并使用您公正的意见来做出购买决定。我们BPB可以了解您对我们产品的看法,我们的作者也可以看到您对他们书籍的反馈。谢谢!
有关BPB的更多信息,请访问 www.bpbonline.com。
加入我们的Discord空间
加入我们的Discord工作区,获取最新更新、优惠、全球科技动态、新版本发布以及与作者的交流机会:
https://discord.bpbonline.com

[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平台模块系统:遗留应用的迁移策略

Java平台模块系统(JPMS)随Java 9引入,代表了该平台最重大的变革之一。对于运行遗留单体应用的组织而言,JPMS通过显式的模块边界和强封装,提供了一条通往更好可维护性、安全性和可扩展性的道路。然而,迁移需要周密的规划和策略。本文为成功将遗留Java应用迁移至模块化架构提供了实用指南。

理解JPMS解决的问题

遗留Java单体应用通常存在紧耦合(组件深度交织,导致更改风险高)和弱封装(所有内容全局可访问,增加错误)的问题。其他挑战还包括构建速度慢(微小更改需要完全重建)以及有限的可扩展性(难以独立部署部分功能)。

JPMS通过引入显式的模块边界、强封装和更好的依赖管理来解决这些问题。该模块系统允许您分组包,并严格控制哪些属于公共API,模块会显式声明其依赖项,而不是仅仅依赖类路径。

什么是模块?

模块用于分组包,并严格控制哪些包属于公共API。与Jar文件不同,模块显式声明它们依赖哪些模块,以及它们导出哪些包。模块声明存在于源层次结构根目录下名为 module-info.java 的文件中。

以下是一个基本的模块声明:

module com.company.data {
    requires java.sql;
    requires java.logging;

    exports com.company.data.api;
    // 内部包不会被导出
}

导出包的公共成员将被依赖模块访问,而私有成员则无法访问(即使通过反射,具体取决于Java版本设置)。

迁移准备

在着手模块化之前,您需要了解应用程序的结构和依赖关系。

步骤1:分析依赖关系

JDeps(Java依赖分析工具)是一个命令行工具,用于处理Java字节码并分析类之间静态声明的依赖关系。该工具对于迁移规划至关重要。

在您的应用程序上运行 jdeps 以获取依赖关系概览:

jdeps -s myapp.jar

这将提供一个摘要,显示您的应用程序依赖哪些JDK模块。要进行更详细的分析:

jdeps --class-path 'libs/*' -summary -recursive myapp.jar

步骤2:识别JDK内部API使用情况

最关键的迁移挑战之一是识别对JDK内部API的依赖,这些API在Java 9+中不再可访问。使用 jdeps 查找这些有问题的依赖:

jdeps -jdkinternals myapp.jar

如果您使用了内部API,jdeps 可能会建议替换方案以帮助您更新代码。例如,如果您的代码使用了 sun.misc.BASE64Encoderjdeps 将建议改用 java.util.Base64

步骤3:创建依赖关系图

理解应用程序的一个有效方法是使用分层图,以分层方式表示依赖关系。这有助于识别哪些组件可以迁移以及迁移顺序。

您可以生成DOT文件用于可视化:

jdeps --dot-output . myapp.jar

然后使用像Graphviz这样的工具或像 webgraphviz.com 这样的在线服务来可视化生成的 .dot 文件。

步骤4:识别循环依赖

JPMS禁止模块之间存在循环依赖。解决此问题的常用方法是创建一个包含共享代码的中间模块,从而打破循环。

例如,如果模块A依赖于B,而模块B又依赖于A,您需要将共享功能提取到一个新的模块C中,让A和B都依赖于C。

迁移策略:自顶向下 vs 自底向上

JPMS支持两种主要的迁移策略,每种策略适用于不同的场景。

自底向上迁移

在此策略中,最初所有JAR文件都位于类路径上。然后,通过一个逐步的过程,所有JAR都可以逐个迁移到模块路径上。

过程:

  1. 选择最低层级的模块:从对您的其他JAR没有依赖关系的模块开始。
  2. 添加 module-info.java:创建一个模块描述符,定义其依赖项和导出项。
  3. 移动到模块路径:此JAR成为命名模块。
  4. 向上重复:继续处理下一层级的模块。

一个三层应用程序(Utils → Services → Application)的示例进展:

# 步骤1:模块化Utils(无内部依赖)
jdeps --generate-module-info . utils.jar

# 步骤2:模块化Services(依赖于Utils)
jdeps --generate-module-info . services.jar

# 步骤3:模块化Application(依赖于两者)
jdeps --generate-module-info . application.jar

自底向上迁移允许底层模块强制执行强封装,而上层模块在过渡期间仍可以访问模块化和非模块化的依赖项。

自顶向下迁移

在此策略中,最初所有JAR文件都位于模块路径上,因此所有未迁移的项目都被视为自动模块。然后,您选择依赖层次结构中尚未迁移的最高层级的项目。

过程:

  1. 将所有JAR放在模块路径上:非模块化JAR成为自动模块。
  2. 从顶部开始:首先模块化您的主应用程序模块。
  3. 添加 module-info.java:使用自动模块名称定义依赖项。
  4. 向下工作:逐渐用适当的命名模块替换自动模块。

自顶向下迁移鼓励在更高层级进行仔细的API设计,并允许您的主应用程序代码立即从模块化中受益。

理解模块类型

在迁移过程中,您将处理三种类型的模块:

命名模块(显式模块)

显式模块遵循其模块声明(module-info.java)中定义的依赖项和API规则。这些是具有完整模块描述符的完全模块化JAR。

自动模块

自动模块是位于模块路径上的普通JAR(无模块描述符)。模块名称源自JAR文件名或 MANIFEST.MF 文件中的 Automatic-Module-Name 条目。

自动模块在迁移期间提供了一个桥梁:

  • 它们可以读取所有其他模块
  • 它们导出其所有包
  • 其他命名模块可以依赖它们

未命名模块

类路径上的所有内容都成为未命名模块的一部分。未命名模块可以读取所有其他模块,但不能被命名模块所需。这提供了向后兼容性。

使用 jdeps 生成模块描述符

jdeps 命令可以为指定的JAR文件生成 module-info.java 文件:

# 生成模块描述符
jdeps --generate-module-info output-dir myapp.jar dependency.jar

# 生成开放模块(用于反射密集型代码)
jdeps --generate-open-module output-dir myapp.jar

生成的 module-info.java 文件提供了一个起点,但您应该审查并完善它们,以正确封装内部包。

处理常见的迁移挑战

拆分包

一个包不能存在于多个模块中。如果您有拆分包,您需要进行重构或合并,以避免同一个包分布在多个模块中。

反射密集型框架

如果框架使用反射(例如 Spring, Hibernate),请声明 opens 以允许访问:

module com.company.data {
    requires java.sql;

    exports com.company.data.api;
    opens com.company.data.entities to org.hibernate.core;
}

opens 指令允许对包进行反射访问,而无需将其导出到公共API。

第三方库

某些第三方库可能尚未模块化;在这些情况下,请使用自动模块或模块修补。随着生态系统的成熟,越来越多的库正在添加模块支持。

对于没有模块的库,请确保它们的 MANIFEST.MF 中有一个 Automatic-Module-Name,或者向上游贡献一个。

更新构建工具

Maven 配置
使用 maven-compiler-plugin 并配置 --module-path--patch-module 选项:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <release>17</release>
    </configuration>
</plugin>

Gradle 配置
使用支持模块化的 java-library 插件:

plugins {
    id 'java-library'
}

java {
    modularity.inferModulePath = true
}

实践示例:模块化一个三层应用程序

让我们逐步完成一个典型的分层应用程序(包含数据层、服务层和API层)的模块化过程。

步骤1:数据层模块

// 数据层的 module-info.java
module com.company.app.data {
    requires java.sql;
    requires java.logging;

    exports com.company.app.data.api;
    // 内部包不导出
}

编译和打包:

javac -d mods/com.company.app.data src/com/company/app/data/**/*.java
jar --create --file mods/com.company.app.data.jar -C mods/com.company.app.data .

步骤2:服务层模块

// 服务层的 module-info.java
module com.company.app.service {
    requires com.company.app.data;
    requires java.logging;

    exports com.company.app.service.api;
}

使用模块路径编译:

javac --module-path mods -d mods/com.company.app.service \
    src/com/company/app/service/**/*.java

步骤3:应用程序模块

// 应用程序的 module-info.java
module com.company.app {
    requires com.company.app.service;
    requires com.company.app.data;
    requires java.logging;
}

运行模块化应用程序:

java --module-path mods -m com.company.app/com.company.app.Main

测试您的模块化应用程序

运行完整的单元测试和集成测试,以验证模块边界。测试确保:

  • 所有必需的模块都已正确声明
  • 导出的包对于依赖模块是足够的
  • 没有发生非法访问尝试
  • 基于反射的框架能通过 opens 指令正常工作

用于兼容性的命令行选项

在迁移期间,您可能需要临时的变通方案。Java提供了几个命令行选项:

  • --add-exports:将一个模块的包导出给另一个模块
  • --add-opens:为一个包开放深度反射权限
  • --add-reads:使一个模块读取另一个模块
  • --patch-module:覆盖或扩充模块的内容

这些选项应作为临时解决方案,同时您需要适当地重构代码。

迁移后的好处

成功迁移后,您将获得:强封装(模块显式控制API)、更好的依赖管理(具有清晰的模块边界)、更高的安全性(通过减少攻击面)以及更快的启动时间(通过优化的模块图)。

模块化的JDK本身展示了这些好处——您可以使用 jlink 创建仅包含应用程序所需模块的自定义运行时映像,从而显著减小部署大小。

最佳实践

成功迁移到JPMS需要遵循成熟的模式并避免常见的陷阱。以下最佳实践源自现实世界的迁移经验,代表了已成功模块化大型Java应用程序的团队的集体智慧。遵循这些指南将帮助您避免代价高昂的错误,并确保顺利过渡到模块化架构。

最佳实践 描述 重要性
从 Java 9+ 兼容性开始 在尝试模块化之前,确保您的应用程序可以在 Java 9+ 上运行 将运行时问题与模块相关问题分开,使调试更容易
增量迁移 不要试图一次性模块化所有内容;选择自底向上或自顶向下策略并系统地进行 降低风险,允许从早期模块中学习,并保持应用程序稳定性
策略性使用自动模块 将自动模块视为迁移期间的临时桥梁,而不是最终目标 自动模块缺乏适当的封装,应替换为显式模块
审查生成的描述符 始终审查和完善由 jdeps 生成的 module-info.java 文件 生成的描述符是起点,可能会过度导出或错过重要的封装机会
积极封装 仅导出真正属于公共API的包;隐藏内部包 强封装防止紧耦合,使重构更安全
文档化模块依赖关系 维护关于模块边界、职责和依赖关系的清晰文档 帮助团队理解模块图并在开发过程中做出明智决策
彻底测试 在每次模块迁移后运行全面的单元测试和集成测试 模块化改变了可见性和访问模式,可能会破坏基于反射的代码
监控非法访问 在测试期间使用 --illegal-access=warn--illegal-access=deny 在内部API导致生产问题之前识别依赖它们的代码
规划循环依赖 通过将共享功能提取到单独的模块中,及早识别并解决循环依赖 JPMS禁止模块间的循环依赖,因此必须对它们进行重构
一致的模块版本管理 在模块生态系统中使用一致的版本控制方案 简化依赖管理并使故障排除更容易

结论

将遗留Java单体应用迁移到使用JPMS的模块化Java是一项重大但有益的工作。通过周密的规划、重构和测试,您可以获得更好的可维护性、性能和安全性等好处。

关键是为您的应用程序选择正确的策略——对于依赖关系较少的库和组件使用自底向上,对于希望在应用程序级别立即受益的应用使用自顶向下。广泛使用 jdeps 来了解您当前的状态并指导您的迁移决策。

虽然模块化可以说是Java有史以来最令人望而生畏的特性之一,并且适当的模块在Java世界中仍然很少见,但对于大规模应用程序而言,强封装、显式依赖关系和更高的安全性所带来的好处使得迁移工作是值得的。


【注】本文译自:Java Platform Module System: Migration Strategies for Legacy Applications

Java记录类入门:简化的以数据为中心的Java编程

记录类声明是一种在Java类中封装数据同时减少样板代码的高效方式。本文将通过基础及高级编程场景介绍其工作原理。

文件柜中的文件记录 图片来源:Stokkete / Shutterstock*

Java记录类是一种用于存储数据的新型类。无需编写构造方法、访问器、equals()hashCode()toString() 的样板代码,只需声明字段,Java编译器便会自动处理其余部分。本文将通过基础与高级用例示例,以及不适用记录类的场景,带您全面了解Java记录类。

注意:Java记录类在JDK 16中正式定型。

Java编译器如何处理记录类

传统Java创建简单数据类需要大量样板代码。以下通过Java吉祥物Duke和Juggy的示例说明:

public class JavaMascot {
    private final String name;
    private final int yearCreated;

    public JavaMascot(String name, int yearCreated) {
        this.name = name;
        this.yearCreated = yearCreated;
    }

    public String getName() { return name; }
    public int getYearCreated() { return yearCreated; }

    // 为简洁起见,省略equals、hashCode和toString方法
}

使用记录类后,上述代码可简化为单行:

public record JavaMascot(String name, int yearCreated) {}

这一简洁声明自动提供了私有final字段、构造方法、访问器方法,以及正确实现的 equals()hashCode()toString() 方法。

定义记录类后,即可投入使用:

public class RecordExample {
    public static void main(String[] args) {
        JavaMascot duke = new JavaMascot("Duke", 1996);
        JavaMascot juggy1 = new JavaMascot("Juggy", 2005);
        JavaMascot juggy2 = new JavaMascot("Juggy", 2005);

        System.out.println(duke); // 输出:JavaMascot[name=Duke, yearCreated=1996]
        System.out.println(juggy1.equals(juggy2)); // 输出:true
        System.out.println(duke.equals(juggy1));   // 输出:false
        System.out.println("吉祥物名称:" + duke.name());
        System.out.println("创建年份:" + duke.yearCreated());
    }
}

记录类自动提供有意义的字符串表示、基于值的等值比较,以及与组件名称匹配的简单访问器方法。

自定义记录类

虽然记录类设计简洁,但仍可通过自定义行为增强功能。以下是相关示例。

紧凑型构造方法

记录类提供特殊的“紧凑型构造方法”语法,无需重复参数列表即可验证或转换输入参数:

record JavaMascot(String name, int yearCreated) {
    // 带验证的紧凑型构造方法
    public JavaMascot {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("名称不能为空");
        }
        if (yearCreated < 1995) {
            throw new IllegalArgumentException("Java吉祥物在1995年前不存在");
        }
    }
}

紧凑型构造方法在字段初始化后、对象完全构建前运行,非常适合用于参数验证。此示例中省略了参数声明,但这些参数在构造方法内仍隐式可用。

添加方法

我们还可以为记录类添加方法:

record JavaMascot(String name, int yearCreated) {
    public boolean isOriginalMascot() {
        return name.equals("Duke");
    }

    public int yearsActive() {
        return java.time.Year.now().getValue() - yearCreated;
    }
}

通过添加方法,记录类可在保持语法简洁和不可变性的同时,封装与其数据相关的行为。

接下来,我们探讨记录类更高级的用法。

使用 instanceofswitch 进行模式匹配

Java 21中,记录类成为模式匹配的关键部分,支持switch表达式、组件解构、嵌套模式和守卫条件。

结合增强的 instanceof 运算符,记录类可在类型验证时简洁地提取组件:

record Person(String name, int age) {}

if (obj instanceof Person person) {
    System.out.println("姓名:" + person.name());
}

再看一个经典示例。几何形状是展示密封接口如何与记录类协同工作的典型例子,这种组合使模式匹配尤为清晰。Switch表达式(Java 17引入)的优雅性在此凸显,它让代码简洁且类型安全,类似于函数式语言中的代数数据类型:

sealed interface Shape permits Rectangle, Circle, Triangle {}

record Rectangle(double width, double height) implements Shape {}
record Circle(double radius) implements Shape {}
record Triangle(double base, double height) implements Shape {}

public class RecordPatternMatchingExample {
    public static void main(String[] args) {
        Shape shape = new Circle(5);

        // 表达性强且类型安全的模式匹配
        double area = switch (shape) {
            case Rectangle r -> r.width() * r.height();
            case Circle c    -> Math.PI * c.radius() * c.radius();
            case Triangle t  -> t.base() * t.height() / 2;
        };

        System.out.println("面积 = " + area);
    }
}

此例中,Shape 是密封接口,仅允许 RectangleCircleTriangle 实现。由于类型集合封闭,switch表达式覆盖所有情况,无需 default 分支。

Java中的模式匹配

若想进一步探索记录类与模式匹配,请参阅我的近期教程:《Java基础与高级模式匹配》

将记录类用作数据传输对象

记录类在现代API设计(如REST、GraphQL、gRPC或服务间通信)中作为数据传输对象(DTO)表现卓越。其简洁语法和内置等值比较特性,使其成为服务层间映射的理想选择。例如:

record UserDTO(String username, String email, Set<String> roles) {}
record OrderDTO(UUID id, UserDTO user, List<ProductDTO> items, BigDecimal total) {}

DTO在微服务应用中无处不在。使用记录类可使DTO更健壮(得益于不可变性),更简洁(无需编写构造方法、getter及 equals()hashCode() 等方法)

函数式与并发编程中的记录类

作为不可变数据容器,记录类完美契合函数式与并发编程需求。它们既可作为纯函数的返回类型,也可用于流处理管道,还能安全地在线程间共享数据。

由于字段为final且不可变,记录类避免了一整类线程问题。一旦构建完成,其状态无法更改,因此无需防御性复制或同步即可实现线程安全。参考以下示例:

transactions.parallelStream().mapToDouble(Transaction::amount).sum();

由于记录类不可变,此并行计算天生具备线程安全性。

不适用Java记录类的场景

至此,我们已了解记录类的优势,但它们并非万能替代品。例如,所有记录类隐式继承 java.lang.Record,因此无法继承其他类(但可实现接口)。在需要类继承的场景中,记录类并不适用。

以下是记录类不适用的其他情况。

记录类设计为不可变

记录类组件始终为final,因此不适用于需要可变/有状态对象的场景。以下示例展示了一个依赖状态变化的可变类,而记录类不允许此类操作:

public class GameCharacter {
    private int health;
    private Position position;

    public void takeDamage(int amount) {
        this.health = Math.max(0, this.health - amount);
    }

    public void move(int x, int y) {
        this.position = new Position(this.position.x() + x, this.position.y() + y);
    }
}

记录类不适合复杂行为建模

基于可变状态、复杂业务逻辑或策略模式、访问者模式、观察者模式等设计,更适合使用传统类实现。以下是复杂逻辑不适用于记录类的示例:

public class TaxCalculator {
    private final TaxRateProvider rateProvider;
    private final DeductionRegistry deductions;

    public TaxAssessment calculateTax(Income income, Residence residence) {
        // 复杂逻辑不适用于记录类
    }
}

记录类与某些框架不兼容

部分框架(尤其是ORM)可能无法良好支持记录类。序列化或重度依赖反射的工具也可能存在问题。请务必检查Java特性与技术栈的兼容性:

// 可能无法与某些ORM框架良好协作
record Employee(Long id, String name, Department department) {}

// 此时仍需使用传统实体类
@Entity
public class Employee {
    @Id
    @GeneratedValue
    private Long id;
    private String name;
    @ManyToOne
    private Department department;

    // Getter、setter、equals、hashCode等方法
}

这些注意事项并不意味着记录类功能不完整,而是强调记录类专为特定场景设计。在某些情况下,传统类仍是更实用的选择。

Java中的记录类与序列化

记录类已在Java生态中被广泛采用,其不可变性使其在持久化、配置和数据传输中极具吸引力。记录类可像普通类一样实现 Serializable 接口。可序列化的记录类组件天然适用于保存配置、恢复状态、网络传输数据或缓存值等场景。

由于记录类字段为final且不可变,它们有助于避免可变状态在序列化与反序列化之间发生变化引发的问题。例如:

import java.io.Serializable;

record User(String username, int age, Profile profile) implements Serializable {}

class Profile {
    private String bio;
}

此例中,Stringint 可序列化,但 Profile 不可序列化,因此 User 无法序列化。若将 Profile 也改为实现 Serializable,则 User 将完全可序列化:

class Profile implements Serializable {
    private String bio;
}

除序列化基础外,Java生态对记录类的支持已迅速成熟。Spring Boot、Quarkus和Jackson等流行框架均与记录类无缝协作,大多数测试工具也是如此。

得益于这种广泛采纳,记录类在实际API中作为DTO表现卓越:

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @GetMapping("/{id}")
    public OrderView getOrder(@PathVariable UUID id) {
        // 实际应用中,此数据应来自数据库或服务
        return new OrderView(
            id,
            "Duke",
            List.of(new ItemView(UUID.randomUUID(), 2)),
            new BigDecimal("149.99")
        );
    }

    // 用于API响应的记录类DTO
    record OrderView(UUID id, String customerName, List<ItemView> items, BigDecimal total) {}
    record ItemView(UUID productId, int quantity) {}
}

如今,大多数主流Java库和工具已将记录类视为一等公民。早期的质疑已基本消散,开发者正因其清晰性与安全性而广泛接纳记录类。

结语

记录类是Java演进过程中的重大进步。它们降低了数据类的冗余度,并确保了不可变性和行为一致性。通过消除构造方法、访问器及 equals()hashCode() 等方法的样板代码,记录类使代码更简洁、表达力更强,在保持类型安全的同时契合现代实践。

记录类并非适用于所有场景,但在处理不可变数据时优势显著。结合模式匹配,它们能让代码意图更清晰,同时由Java编译器处理样板代码。

随着记录类、密封类和模式匹配等技术的进步,Java正稳步迈向更以数据为中心的编程风格。掌握这些工具是编写现代、高表达力Java代码的最清晰路径之一。


【注】本文译自:Introduction to Java records: Simplified data-centric programming in Java

在企业级 Java 中应用领域驱动设计:一种行为驱动方法

了解如何结合 DDD 和 BDD 于企业级 Java 中,以创建能够模拟真实业务领域并通过可执行场景验证行为的软件。

在软件开发领域,最大的错误之一就是交付客户"精确"想要的东西。这听起来可能像陈词滥调,但即使在行业摸爬滚打数十年后,这个问题依然存在。一个更有效的方法是从关注业务需求开始测试。

行为驱动开发Behavior-driven development】(BDD)是一种强调行为和领域术语(也称为统一语言)的软件开发方法论。它使用共享的自然语言,从用户的角度定义和测试软件行为。BDD 建立在测试驱动开发test-driven development】(TDD)的基础上,专注于与业务相关的场景。这些场景以纯语言规范的形式编写,可以自动化成测试,同时也充当活文档。

这种方法促进了技术和非技术利益相关者之间的共识,确保软件满足用户需求,并有助于减少返工和开发时间。在本文中,我们将进一步探讨这种方法论,并讨论如何使用 Oracle NoSQL 和 Java 来实现它。

BDD 与 DDD 如何协同工作

乍看之下,行为驱动开发(BDD)和领域驱动设计(DDD)似乎解决的是不同的问题——一个侧重于测试,另一个侧重于建模。然而,它们共享相同的哲学基础:确保软件真实反映其所服务的业务领域

DDD,由 Eric Evans 在其 2003 年具有开创性的著作《领域驱动设计:软件核心复杂性的应对之道》中提出,教导我们围绕业务概念(实体、值对象、聚合和限界上下文)来建模软件。其力量在于使用统一语言,这是一种连接开发人员和领域专家的共享词汇表。

BDD,由 Dan North 在几年后提出,是这一思想自然而然的延伸。它将统一语言引入测试过程,将业务规则转化为可执行的规范。DDD 定义了系统应该表示什么,而 BDD 则根据该模型验证系统的行为方式

当结合使用时,DDD 和 BDD 形成了一个持续的反馈循环:

  • DDD 塑造了捕获业务逻辑的领域模型
  • BDD 确保系统行为随着时间的推移与该模型保持一致。

在实践中,这种协同作用意味着您可以编写与聚合(如 Room 和 Reservation)直接相关的特性场景——例如"当我预订一个 VIP 房间时,系统应将其标记为不可用"。这些测试成为开发人员和利益相关者的活文档,确保您的领域始终与真实的业务需求保持一致。

如果您想深入探索这种结合,我的著作《Domain-Driven Design with Java》详细阐述了这些原则。它展示了如何在现代 Java 应用程序中使用 Jakarta EE、Spring 和云技术应用 DDD 模式,为统一架构和行为提供了实践基础。

总之,DDD 和 BDD 共同弥合了理解业务与证明其可行之间的差距——将软件从技术制品转变为领域本身的忠实表达。

代码实现

在本示例中,我们将使用企业级 Java 和 Oracle NoSQL 数据库生成一个简单的酒店管理应用程序。

第一步是创建项目。由于我们使用的是 Java SE,我们可以使用以下 Maven 命令生成它:

mvn archetype:generate                     \
"-DarchetypeGroupId=io.cucumber"           \
"-DarchetypeArtifactId=cucumber-archetype" \
"-DarchetypeVersion=7.30.0"                \
"-DgroupId=org.soujava.demos.hotel"        \
"-DartifactId=behavior-driven-development" \
"-Dpackage=org.soujava.demos"              \
"-Dversion=1.0.0-SNAPSHOT"                 \
"-DinteractiveMode=false"

下一步是引入 Eclipse JNoSQLOracle NoSQL,以及 Jakarta EE 组件的实现:CDI、JSON 和 Eclipse MicroProfile 实现。

您可以找到完整的 pom.xml 文件。

初始项目准备就绪后,我们将从创建测试开始。

请记住,BDD 是 TDD 的扩展,它包含了统一语言——领域和业务之间的共享词汇。

功能: 管理酒店房间

  场景: 注册一个新房间
    假设 酒店管理系统正在运行
    当 我注册一个号码为 203 的房间
    那么 号码为 203 的房间应该出现在房间列表中

  场景: 注册多个房间
    假设 酒店管理系统正在运行
    当 我注册以下房间:
      | number | type      | status             | cleanStatus |
      | 101    | STANDARD  | AVAILABLE          | CLEAN       |
      | 102    | SUITE     | RESERVED           | DIRTY       |
      | 103    | VIP_SUITE | UNDER_MAINTENANCE  | CLEAN       |
    那么 系统中应该有 3 个可用房间

  场景: 更改房间状态
    假设 酒店管理系统正在运行
    并且 一个号码为 101 的房间已注册为 AVAILABLE
    当 我将房间 101 标记为 OUT_OF_SERVICE
    那么 房间 101 应被标记为 OUT_OF_SERVICE

Maven 项目完成后,让我们进入下一步,即创建建模和存储库。如前所述,我们将专注于房间管理。因此,我们的下一个目标是确保之前定义的 BDD 测试通过。让我们从实现领域模型和存储库开始:

public enum CleanStatus {
    CLEAN,       // 清洁
    DIRTY,       // 脏污
    INSPECTION_NEEDED // 需要检查
}

public enum RoomStatus {
    AVAILABLE,         // 可用
    RESERVED,          // 已预订
    UNDER_MAINTENANCE, // 维护中
    OUT_OF_SERVICE     // 停止服务
}

public enum RoomType {
    STANDARD,  // 标准间
    DELUXE,    // 豪华间
    SUITE,     // 套房
    VIP_SUITE  // VIP套房
}

@Entity
public class Room {

    @Id
    private String id;

    @Column
    private int number; // 房间号

    @Column
    private RoomType type; // 房间类型

    @Column
    private RoomStatus status; // 房间状态

    @Column
    private CleanStatus cleanStatus; // 清洁状态

    @Column
    private boolean smokingAllowed; // 允许吸烟

    @Column
    private boolean underMaintenance; // 处于维护状态

}

有了模型,下一步是创建企业级 Java 与作为非关系型数据库的 Oracle NoSQL 之间的桥梁。我们可以使用 Jakarta Data 非常轻松地完成,它只有一个存储库接口,所以我们不需要担心实现。

@Repository
public interface RoomRepository {

    @Query("FROM Room")
    List<Room> findAll();

    @Save
    Room save(Room room);

    void deleteBy();

    Optional<Room> findByNumber(Integer number);
}

项目完成后,下一步是准备测试环境,首先提供一个数据库实例用于测试。多亏了 Testcontainers,我们可以轻松启动一个隔离的 Oracle NoSQL 实例来运行我们的测试。

public enum DatabaseContainer {

    INSTANCE;

    private final GenericContainer<?> container = new GenericContainer<>
            (DockerImageName.parse("ghcr.io/oracle/nosql:latest-ce"))
            .withExposedPorts(8080);

    {
        container.start();
    }
    public DatabaseManager get(String database) {
        DatabaseManagerFactory factory = managerFactory();
        return factory.apply(database);
    }

    public DatabaseManagerFactory managerFactory() {
        var configuration = DatabaseConfiguration.getConfiguration();
        Settings settings = Settings.builder()
                .put(OracleNoSQLConfigurations.HOST, host())
                .build();
        return configuration.apply(settings);
    }

    public String host() {
        return "http://" + container.getHost() + ":" + container.getFirstMappedPort();
    }
}

之后,我们将创建一个与 @Alternative CDI 注解集成的生产者。此配置指导 CDI 如何提供数据库实例——在本例中是由 Testcontainers 管理的实例:

@ApplicationScoped
@Alternative
@Priority(Interceptor.Priority.APPLICATION)
public class ManagerSupplier implements Supplier<DatabaseManager> {

    @Produces
    @Database(DatabaseType.DOCUMENT)
    @Default
    public DatabaseManager get() {
        return DatabaseContainer.INSTANCE.get("hotel");
    }

}

借助 Cucumber,我们可以定义一个将类注入到 Cucumber 测试上下文中的 ObjectFactory。由于我们使用 CDI 并以 Weld 作为实现,我们将创建一个自定义的 WeldCucumberObjectFactory 来无缝集成这两种技术。

public class WeldCucumberObjectFactory implements ObjectFactory {

    private Weld weld;
    private WeldContainer container;

    @Override
    public void start() {
        weld = new Weld();
        container = weld.initialize();
    }

    @Override
    public void stop() {
        if (weld != null) {
            weld.shutdown();
        }
    }

    @Override
    public boolean addClass(Class<?> stepClass) {
        return true;
    }

    @Override
    public <T> T getInstance(Class<T> type) {
        return (T) container.select(type).get();
    }
}

一个重要提示:此设置作为 SPI(服务提供者接口)工作。因此,您必须创建以下文件:

src/test/resources/META-INF/services/io.cucumber.core.backend.ObjectFactory

内容如下:

org.soujava.demos.hotels.config.WeldCucumberObjectFactory

我们将让 Mapper 将我们的数据表转换为所有模型中的 Room 对象。

@ApplicationScoped
public class RoomDataTableMapper {

    @DataTableType
    public Room roomEntry(Map<String, String> entry) {
        return Room.builder()
                .number(Integer.parseInt(entry.get("number")))
                .type(RoomType.valueOf(entry.get("type")))
                .status(RoomStatus.valueOf(entry.get("status")))
                .cleanStatus(CleanStatus.valueOf(entry.get("cleanStatus")))
                .build();
    }
}

整个测试基础设施完成后,下一步是设计包含我们实际测试的 Step 测试类。

@ApplicationScoped
public class HotelRoomSteps {

    @Inject
    private RoomRepository repository;

    @Before
    public void cleanDatabase() {
        repository.deleteBy();
    }

    @Given("the hotel management system is operational")
    public void theHotelManagementSystemIsOperational() {
        Assertions.assertThat(repository).as("RoomRepository 应该已初始化").isNotNull();
    }

    @When("I register a room with number {int}")
    public void iRegisterARoomWithNumber(Integer number) {
        Room room = Room.builder()
                .number(number)
                .type(RoomType.STANDARD)
                .status(RoomStatus.AVAILABLE)
                .cleanStatus(CleanStatus.CLEAN)
                .build();
        repository.save(room);
    }

    @Then("the room with number {int} should appear in the room list")
    public void theRoomWithNumberShouldAppearInTheRoomList(Integer number) {
        List<Room> rooms = repository.findAll();
        Assertions.assertThat(rooms)
                .extracting(Room::getNumber)
                .contains(number);
    }

    @When("I register the following rooms:")
    public void iRegisterTheFollowingRooms(List<Room> rooms) {
        rooms.forEach(repository::save);
    }

    @Then("there should be {int} rooms available in the system")
    public void thereShouldBeRoomsAvailableInTheSystem(int expectedCount) {
        List<Room> rooms = repository.findAll();
        Assertions.assertThat(rooms).hasSize(expectedCount);
    }

    @Given("a room with number {int} is registered as {word}")
    public void aRoomWithNumberIsRegisteredAs(Integer number, String statusName) {
        RoomStatus status = RoomStatus.valueOf(statusName);
        Room room = Room.builder()
                .number(number)
                .type(RoomType.STANDARD)
                .status(status)
                .cleanStatus(CleanStatus.CLEAN)
                .build();
        repository.save(room);
    }

    @When("I mark the room {int} as {word}")
    public void iMarkTheRoomAs(Integer number, String newStatusName) {
        RoomStatus newStatus = RoomStatus.valueOf(newStatusName);
        Optional<Room> roomOpt = repository.findByNumber(number);

        Assertions.assertThat(roomOpt)
                .as("房间 %s 应该存在", number)
                .isPresent();

        Room updatedRoom = roomOpt.orElseThrow();
        updatedRoom.update(newStatus); // 假设 Room 类有 update 方法

        repository.save(updatedRoom);
    }

    @Then("the room {int} should be marked as {word}")
    public void theRoomShouldBeMarkedAs(Integer number, String expectedStatusName) {
        RoomStatus expectedStatus = RoomStatus.valueOf(expectedStatusName);
        Optional<Room> roomOpt = repository.findByNumber(number);

        Assertions.assertThat(roomOpt)
                .as("房间 %s 应该存在", number)
                .isPresent()
                .get()
                .extracting(Room::getStatus)
                .isEqualTo(expectedStatus);
    }
}

是时候执行测试了:

mvn clean test

您可以看到结果:

INFO: Connecting to Oracle NoSQL database at http://localhost:61325 using ON_PREMISES deployment type
  ✔ Given the hotel management system is operational      # org.soujava.demos.hotels.HotelRoomSteps.theHotelManagementSystemIsOperational()
  ✔ And a room with number 101 is registered as AVAILABLE # org.soujava.demos.hotels.HotelRoomSteps.aRoomWithNumberIsRegisteredAs(java.lang.Integer,java.lang.String)
  ✔ When I mark the room 101 as OUT_OF_SERVICE            # org.soujava.demos.hotels.HotelRoomSteps.iMarkTheRoomAs(java.lang.Integer,java.lang.String)
  ✔ Then the room 101 should be marked as OUT_OF_SERVICE  # org.soujava.demos.hotels.HotelRoomSteps.theRoomShouldBeMarkedAs(java.lang.Integer,java.lang.String)
Oct 21, 2025 6:18:43 PM org.jboss.weld.environment.se.WeldContainer shutdown
INFO: WELD-ENV-002001: Weld SE container fc4b3b51-fba8-4ea6-9cef-42bcee97d220 shut down
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.231 s -- in org.soujava.demos.hotels.RunCucumberTest
[INFO] Running org.soujava.demos.hotels.MongoDBTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 s -- in org.soujava.demos.hotels.MongoDBTest
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO] 

结论

通过结合领域驱动设计(DDD)和行为驱动开发(BDD),开发人员可以超越技术正确性,构建真正反映业务意图的软件。DDD 为领域提供了结构,确保模型精确地捕捉现实世界的概念,而 BDD 则通过用业务本身的语言编写的清晰、可测试的场景,确保这些模型按预期运行。

在本文中,您学习了如何使用 Oracle NoSQL、Eclipse JNoSQL 和 Jakarta EE 连接这两个世界——从定义您的领域到运行由 Cucumber 和 CDI 支持的真实行为测试。这种协同作用将测试转化为活文档,弥合了工程师和利益相关者之间的差距,并确保您的系统在演进过程中始终与业务目标保持一致。

您可以深入探索并将 DDD 与 BDD 结合起来。在《Domain-Driven Design with Java》这本书中,您可以找到一个很好的起点来理解为什么 DDD 对我们仍然很重要。它扩展了这里分享的想法,展示了 DDD 和 BDD 如何共同带来更简单、更易维护且以业务为中心的软件。这种软件交付的是超越需求的实际价值。


【注】本文译自:Applying Domain-Driven Design With Enterprise Java: A Behavior-Driven Approach

Java 应用容器化与部署

如何开始打包、分发并将 Java 交付至生产环境

应用程序的容器化 提供了一种方法,可以将所有必需的应用程序资源——包括程序和配置文件、环境变量、网络设置等——组合到一个标准化、易于管理的包中。

从单个容器镜像可以启动、运行、管理和终止多个功能相同的容器,确保从镜像创建点开始的一致性。容器可以在截然不同的操作平台上运行,从本地机器到全球可扩展的云环境,以及介于两者之间的一切。可以构建流水线,轻松地在它们之间过渡。
虽然应用程序容器化有许多好处,但许多都可以归结为一个词:一致性

为何要对 JAVA 应用进行容器化?

Java 早期的一个承诺是"一次编写,到处运行",即"WORA"。尽管 Java 通过其 Java 虚拟机(JVM)实现了某种形式的目标,但在实现真正无缝的体验方面仍然存在相当多的外部障碍。
容器化解决了几乎所有这些外部障碍。虽然 100% 在任何追求中都可能是一个难以实现的目标,但将 Java 应用程序的可执行文件及其所有必需的依赖项和支持属性(配置等)打包的能力,使我们达到了有效的 100% 可移植性和一致性水平。

为 JAVA 应用程序创建 DOCKERFILE

许多开发人员通过仔细阅读官方的 Dockerfile 参考文档来开始他们的容器化工作。为了立即获得良好效果,让我们介绍关键点,创建一些镜像,并在此基础上进行构建。

为容器化选择操作系统和 JDK 构建

对此有各种不同的观点,但如果您刚开始接触容器化,从一个较小但完整的操作系统(OS)开始是一个很好的第一步。我们稍后将讨论其他选项(例如,无发行版)。
一般来说,您在操作系统层包含的内容越多,容器镜像就越大,安全漏洞的攻击面也就越大。可信来源也是一个关键的考虑因素。如果使用完整的操作系统构建,强烈推荐使用 eclipse-temurin(基于 Ubuntu)或 Alpine 基础层。
任何 OpenJDK 的构建都能运行您基于 JVM 的 Java 应用程序,而 Eclipse Temurin 是众多良好选项之一。但是,如果您希望对可能发现的任何 Java 问题获得专门的生产支持,那么选择商业支持的构建可以提供这种支持。

JAVA 应用的基本 DOCKERFILE 结构

一个基本 Java 应用程序的最低可行 Dockerfile 看起来像这样:

FROM eclipse-temurin:latest
COPY java-in-the-can-0.0.1-SNAPSHOT.jar /app.jar
EXPOSE 8080
CMD ["java", "-jar", "/app.jar"]

将上述文本(在 COPY 指令中使用您应用程序的名称)保存在一个名为 Dockerfile 的文件中,该文件与您的 Java 应用程序(.jar)文件位于同一目录。
在上面的 Dockerfile 中,我们提供了构建容器镜像的基本信息:

  • 构建应用程序容器镜像所基于的更高层基础镜像FROM
  • 将 .jar 文件复制COPY)到镜像中(在此示例中,还进行了重命名)的命令
  • 为应用程序监听连接请求而需要暴露EXPOSE)的任何特定端口(如有必要)
  • 在容器启动时运行应用程序的命令CMD
    在包含您的 Dockerfile 和 .jar 文件的目录中执行以下命令:
docker build -t <app-image-name> .

请注意,在运行镜像创建和其他容器命令之前,docker 守护进程(或 Mac/Windows 上的 Docker Desktop、Podman 等)必须正在运行。另外,不要忘记命令末尾的 .;它指的是可以找到 Dockerfile 的当前目录。
以这种方式运行生成的应用程序容器,用您上面创建的容器镜像名称替换 <app-image-name>

docker run -p 8080:8080 <app-image-name>

选择无发行版操作系统+JDK 基础镜像

对于大多数用例,在大小和攻击面方面可实现的最佳优化可能由"无发行版"基础镜像提供。虽然无发行版基础镜像中确实包含一个 Linux 发行版,但它已被剥离了任何非当前目的 specifically 不需要的文件,留下一个完全精简的操作系统,对于无发行版 Java 镜像而言,还包括 JVM。以下是一个使用无发行版 Java 基础镜像的 Dockerfile 示例:

FROM mcr.microsoft.com/openjdk/jdk:21-distroless
COPY java-in-the-can-0.0.1-SNAPSHOT.jar /app.jar
EXPOSE 8080
CMD ["-Xmx256m", "-jar", "/app.jar"]

请注意,这个针对 Java 优化的基础镜像预先配置了 java 命令的 ENTRYPOINT,因此 CMD 指令用于为 JVM 启动器进程提供命令行参数。

使用多阶段构建来减小镜像大小

如果您有构建所需但最终输出不需要的文件,多阶段构建提供了减小容器镜像大小的方法。就本文参考而言,情况并非如此,因为 JVM 以及应用程序的 .jar 文件和依赖项已为镜像创建预先配置好了。
正如您可能想象的那样,在某些非常常见的情况下,这变得有利。通常,应用程序通过配置好的构建流水线部署到生产环境,这些流水线基于源仓库上的触发器来创建构件。这是多阶段构建的最佳用例之一:构建流水线创建一个带有适当工具的构建容器,使用它来创建构件(例如 .jar 文件、配置文件),然后将这些构件复制到一个新的容器镜像中,该镜像不包含生产环境不需要的额外工具。这一系列操作大致类似于我们之前手动完成的操作,但实现了自动化,以获得一致和最优的结果。

管理环境变量

有多种方法可以向容器和应用程序提供输入值,用于启动或执行。一个应该采用的良好实践是,尽可能使用 ENVENTRYPOINTCMD 指令在 Dockerfile 本身中指定所有可能的值。所有这些值都可以在容器初始化时根据需要覆盖。
请注意,覆盖现有环境变量时应谨慎,因为这可能会以意外和不良的方式改变应用程序行为。
使用 ENV 配置 Java 特定选项的示例:

ENV JAVA_OPTS="-Xmx512m -Xms256m"

相同的概念也适用于应用程序特定变量:

ENV APP_GREETING="Greetings, Friend!"

使用 ENTRYPOINT 配置应用程序特定值的示例:

ENTRYPOINT ["java", "$JAVA_OPTS", "-jar", "your-app.jar"]

使用 CMD 的示例:

CMD ["java", "-Xmx256m", "-jar", "/app.jar"]

您可能已经注意到,ENTRYPOINTCMD 都可以用来执行 Java 应用程序。像所有其他技术(和非技术)选项一样,这两种指令各有优缺点。如果操作得当,两者都会使您的 Java 应用程序运行。
一般来说,Java 应用程序使用 CMD 指令,以便应用程序可以处理操作系统信号,用于支持的钩子机制(例如,SIGTERM 对应 java.lang.Runtime.addShutdownHook)。当然,这并非绝对必要,并且可以(也经常)使用 ENTRYPOINTCMD 来促进运行时参数传递,以提供/覆盖特定行为。这两者并不互斥。

使用 SPRING BOOT 插件进行容器化

如果您使用 Spring Boot 开发 Java 应用程序,容器化会简单得多。无论使用 Maven 还是 Gradle 作为项目构建工具,创建容器镜像都像执行一个预定义的目标一样简单。

  • 如果使用 Maven 作为构建工具,您可以通过调用 build-image 目标来创建包含应用程序的容器镜像:
    ./mvnw spring-boot:build-image
  • 如果使用 Gradle 作为构建工具,您可以通过调用 bootBuildImage 目标来创建包含应用程序的容器镜像:
    ./gradlew bootBuildImage
    在大多数情况下,自定义镜像创建(例如,镜像层定义)既不必要也不可取,但如果需要这样做,请参阅 Spring Boot Maven 或 Gradle 插件文档中的"打包 OCI 镜像"部分。

为原生应用程序构建容器镜像

开发人员可以选择使用 JVM 或作为原生的、操作系统特定的可执行文件来交付 Java 应用程序。以下部分提供了一些关于选择的考虑因素,以及如果您决定使用原生应用程序构建容器镜像,如何以最小的代价实现。

使用 GRAALVM 的 JAVA 原生可执行文件

GraalVM 支持创建原生可执行文件/二进制 Java 应用程序,在构建时执行所有编译和优化,而不是利用 JVM 在运行应用程序字节码时进行一些优化。
与所有选择一样,需要权衡利弊。编译为字节码与原生可执行文件是秒与分钟的问题,并且 JVM 执行的运行时优化在原生可执行文件中消失了,因为代码无法在运行时动态重写(这是 JVM 启用的一个特性)。
原生可执行文件优于基于 JVM 的 Java 应用程序的地方在于文件大小、内存需求和启动时间。原生应用程序要小得多,需要的资源更少,不需要 JVM 存在,并且启动速度显著更快。这在许多生产环境中是非常重要的考虑因素,因为较小的应用程序(及其容器)会降低平台资源需求,并且以毫秒而不是几秒衡量的启动时间可以增加可用性、可扩展性以及系统设计和部署的选项,从而可以显著节省成本。
根据您的框架和工具选择,有几种构建完全可执行的、操作系统原生的 Java 应用程序的选项。然而,一旦您有了原生可执行文件/二进制应用程序,您可以创建一个类似以下的 Dockerfile 作为您的原生应用程序容器镜像的模板:

FROM alpine:latest
WORKDIR /app
COPY java-in-the-can /app/
EXPOSE 8080
CMD ["/app/java-in-the-can"]

如果您使用 Spring Boot,您可以使用 GraalVM Maven 或 Gradle 插件,通过一条命令将您的应用程序编译为操作系统原生应用程序并创建容器镜像。

MAVEN
首先,将此依赖项添加到您的 pom.xml<build><plugins> 部分并保存文件:

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
</plugin>

要构建原生应用程序和容器镜像,从您的项目根目录运行此命令:
./mvnw -Pnative spring-boot:build-image

GRADLE
类似地,将此依赖项添加到您的 build.gradle 文件的 plugins {} 部分并保存:
id 'org.graalvm.buildtools.native'

要构建原生应用程序和容器镜像,从您的项目根目录运行此命令:
./gradlew bootBuildImage

关于减小镜像大小和加快启动时间的考虑因素

您可能已经注意到,上述各节的顺序总体上趋向于生产更精简、启动更快的容器镜像。许多决策可能涉及组织标准或选择(例如,部署标准),这些标准或选择会使天平倾向于或反对某些选择,但一般来说,容器镜像优化的路径遵循以下顺序:

  1. 选择更小的基础镜像(操作系统发行版和 JVM)
  2. 选择带有 JVM 的无发行版镜像
  3. 如果您的工具链(例如 Spring Boot)允许,利用专门构建的工具
  4. 利用带有原生可执行应用程序的精简发行版或无发行版镜像

容器中 JAVA 应用程序的部署策略

您的应用程序的重要考虑因素超出了将其打包成应用程序容器镜像的范围。接下来是部署和维护决策,这些决策对于您的应用程序进入并保持在生产环境至关重要。

单容器部署

对于基本上是自包含的应用程序,部署到生产环境可以像单个命令一样简单,前提是部署目标已准备好接受容器化应用程序。即使在应用程序部署之前必须创建支持资源的情况下,这通常也意味着通过命令行或 Web 门户发出少量指令。当应用程序包含多个容器部署时,进程间依赖关系可能要求按特定顺序部署容器,以确保可用性或最小化波动或 chatter。为了实现这些目标,需要进行编排部署。

编排部署

编排部署可能比单容器部署复杂得多,并相应地提供更多功能。由于这两个特点,与单容器部署相比,编排部署可能有更多平台层级值得考虑。这些层级范围从提供广泛灵活性并相应需要开发人员付出更高水平努力的较低层级 Kubernetes 平台,到完成大量繁重工作以安全配置和集成多个容器和/或服务的完整平台。
您选择的目标平台将决定您对部署工具(例如,脚本、门户、基础设施配置工具)的选择。非常笼统地说,您选择的平台目标应该是能够部署和维护您的应用程序及其相关服务的最简单的平台。其他重要的考虑因素包括应用程序所有必需容器/服务的部署目标之间的比较成本、您组织已建立的实践/流水线等。

构建支持持续打补丁的 JAVA 应用程序

生产部署在应用程序上线后并未完成;开发人员必须确保应用程序保持安全、最新和可用。关键的补丁管理考虑因素包括:

  • 定期补丁 – 为常规补丁(例如,每月或每季度)建立一个无中断、可预测的频率,以更新库和依赖项
  • 紧急补丁 – 提供关于何时需要紧急补丁的指导,通常是为了应对关键漏洞或紧急安全更新
    容器镜像中需要打补丁的组件包括:
  • 基础操作系统容器镜像
  • 附加的操作系统包(如果适用)
  • 应用程序运行时(例如,JVM 版本,如果未包含在基础镜像中)
  • 应用程序依赖项/库
  • 应用程序性能监控(APM)代理二进制文件
    由开发人员及其组织来决定并严格维护一个保护应用程序、系统基础设施和数据的补丁策略。请参考此指南来帮助制定您的具体策略。

结论

容器化使开发人员能够将所有必需的应用程序资源和支持服务组合到一个或多个容器镜像中,并更轻松地部署、运行和管理它们。如果操作得当,容器化可以从镜像创建点开始实现安全性和一致性。容器可以在截然不同的操作平台上运行,从本地机器到全球可扩展的云环境。可以构建流水线,轻松地在它们之间过渡。因此,开发人员构建和运行支持生产工作负载的相同构件,减少了冲突并简化了调优和故障排除。
如果您是容器新手,请从小处着手,在本地构建以获得知识和稳定的基础,然后通过纳入更多容器最佳实践、构建流水线和合适的云平台来"扩展构建",逐步走向强大的应用程序部署生产模型。

其他考虑因素和资源:

作者:MARK A. HECKLER,
微软首席云技术推广专家(Java/JVM 语言)
Mark Heckler 是一名软件开发人员,微软的 Java/JVM 语言首席云技术推广专家,会议演讲者,Java Champion 和 Kotlin 开发专家,专注于为云和边缘计算平台快速开发生产软件。Mark 是开源贡献者,也是《Spring Boot: Up and Running》的作者,可以在 X @mkheck 上找到他。


【注】本文译自:Java Application Containerization and Deployment

使用 Spring AI 创建 MCP 服务器

本文提供了使用 Spring AI 创建模型上下文协议服务器的分步指南,并阐述了使用 MCP 的优势。

在本篇博客中,您将学习如何使用 Spring AI 创建一个模型上下文协议服务器。您将看到创建自己的 MCP 服务器是多么简单。

引言

模型上下文协议(Model Context Protocol)为将大型语言模型(LLM)连接到各种数据源和工具提供了一种标准化的方式。这句话中的"标准化"一词非常重要。这意味着与数据源和工具的集成变得比以往容易得多。除此之外,MCP 服务器通过额外的知识或功能来增强您的 LLM,使其成为一个更强大的助手。想象一下,您可以要求 LLM 为您预订假期。

根据您的偏好,它将在互联网上搜索合适的地点、预订酒店、预订航班等等,然后您就可以出发了!当然,LLM 需要能够为您预订酒店和航班。这种附加功能可以由 MCP 服务器提供。这听起来很吸引人,但也有些令人担忧。为了预订酒店,MCP 服务器需要知道您的个人详细信息并需要访问您的信用卡。这可能不是一个好主意。建议对敏感操作使用人工介入(HITL),以便您可以批准或拒绝某项操作。然而,MCP 服务器将使您的生活变得更加轻松。

在本博客中,您将学习如何使用 Spring Boot 和 Spring AI 创建自己的 MCP 服务器。没有 MCP 客户端,服务器将毫无用处。MCP 客户端与一个或多个 MCP 服务器交互,并且是控制方。作为 MCP 客户端,您将(滥)用 IntelliJ DevoxxGenie 插件。DevoxxGenie 实际上是一个 AI 编码助手,但您也可以使用它来测试您的 MCP 服务器。在下一篇博客中,您将创建自己的 MCP 客户端。

本篇博客中使用的源代码可在 GitHubserver 目录中找到。

先决条件

阅读本博客的先决条件是:

  • 基础的 Java 知识;
  • 基础的 Spring Boot 知识;
  • 基础的 LMStudio 知识;
  • 基础的 IntelliJ 和 DevoxxGenie 知识。

构建 MCP 服务器

您将构建的 MCP 服务器具有以下功能:

  • 返回我喜爱的艺术家列表
  • 返回我喜爱的歌曲列表

LLM 不会拥有关于此信息的任何知识,而当它能够访问这些工具时,希望它会利用它们。本应用深受 Dan Vega 的《使用 Java 创建您的第一个模型上下文协议服务器》的启发。

访问 Spring Initializr 并添加依赖项 Model Context Protocol Server。这将在 pom.xml 中添加以下依赖项。

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-mcp-server</artifactId>
</dependency>

创建 Artist 的数据模型。

public record Artist(String name) {
}

创建 Song 的数据模型。

public record Song(Artist artist, String title) {
}

创建 ArtistService。该服务将包含一个我喜爱的艺术家列表,但在实际应用中,这些信息将存储在数据库中。通过使用 @Tool 注解来定义一个名为 get_artists 的工具。为工具提供名称和描述。LLM 将使用该描述来了解工具的功能。

@Service
public class ArtistService {

    private final List<Artist> artists = new ArrayList<>();

    @Tool(name = "get_artists", description = "获取 Gunter 喜爱的艺术家完整列表")
    public List<Artist> getArtists() {
        return artists;
    }

    @PostConstruct
    public void init() {
        artists.addAll(List.of(
                new Artist("Bruce Springsteen"),
                new Artist("JJ Johnson")
        ));
    }

}

以类似的方式,创建 SongService

@Service
public class SongService {

    private final List<Song> songs = new ArrayList<>();

    @Tool(name = "get_songs", description = "获取 Gunter 喜爱的歌曲完整列表")
    public List<Song> getSongs() {
        return songs;
    }

    @PostConstruct
    public void init() {
        songs.addAll((List.of(
                new Song(new Artist("Bruce Springsteen"), "My Hometown"),
                new Song(new Artist("JJ Johnson"), "Lament")
        )));
    }

}

您通过一个 Bean 来注册这些工具。

@SpringBootApplication
public class MyMcpServerPlanetApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyMcpServerPlanetApplication.class, args);
    }

    @Bean
    public ToolCallbackProvider mcpServices(ArtistService artistService, SongService songService) {
        return MethodToolCallbackProvider.builder()
                .toolObjects(artistService, songService)
                .build();
    }

}

最后,添加以下 application.properties 配置。

spring.main.web-application-type=none
spring.ai.mcp.server.name=mcp-server
spring.ai.mcp.server.version=0.0.1

spring.main.banner-mode=off
logging.pattern.console=

此配置做了几件重要的事情:

  • 禁用 Web 应用程序:由于 MCP 使用 STDIO 传输,因此不需要 Web 服务器。
  • 设置服务器名称和版本:这用于向客户端标识 MCP 服务器。
  • 禁用横幅和控制台日志记录:这对于 STDIO 传输正常工作至关重要。

构建 jar 文件。

mvn clean verify

这将在 target 目录中生成一个 jar 文件:target/mcp-server-0.0.1-SNAPSHOT.jar

测试 MCP 服务器

为了测试 MCP 服务器,需要一个 MCP 客户端。如前所述,将使用 DevoxxGenie 来实现此目的。

将 MCP 服务器添加到 DevoxxGenie 的 MCP 设置中。请注意,您需要对命令和参数使用完整路径。

  • 名称:MyMcpServerPlanet
  • 传输类型:STDIO
  • 命令/<java installation directory>/bin/java
  • 参数-jar /home/<project directory>/mymcpserverplanet/server/target/mymcpserverplanet-0.0.1-SNAPSHOT.jar

Test MCP Server)

单击"测试连接并获取工具"按钮。按钮的标题应变更为"连接成功!找到 2 个工具"。

与 DevoxxGenie 一起,使用 LMStudio 作为推理引擎,模型 qwen3-8b 在 GPU 上运行。

输入提示:给我一个 Gunter 喜爱的艺术家列表。

该请求被发送到 LMStudio,可用的工具也随请求一起发送。如果您在 LMStudio 中启用了调试日志,可以检查该请求。

2025-07-20 11:45:42 [DEBUG]
 Received request: POST to /v1/chat/completions with body  {
  "model": "qwen3-8b",
  "messages": [
    {
      "role": "system",
      "content": "You are a software developer IDEA plugin with expe... <日志中已截断> ...at is correct and relevant to the code or plugin.\n"
    },
    {
      "role": "user",
      "content": "<ProjectPath>\n/home/<project directory>... <日志中已截断> ... list of gunter's favorite artists\n</UserPrompt>\n\n"
    }
  ],
  "temperature": 0,
  "top_p": 0.9,
  "stream": false,
  "max_tokens": 8000,
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_songs",
        "description": "获取 Gunter 喜爱的歌曲完整列表",
        "parameters": {
          "type": "object",
          "properties": {},
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "get_artists",
        "description": "获取 Gunter 喜爱的艺术家完整列表",
        "parameters": {
          "type": "object",
          "properties": {},
          "required": []
        }
      }
    }
  ]
}

LLM 将意识到它自己无法回答这个问题。然而,LLM 确实识别出有一个可用的工具可以回答这个问题。因此,LLM 将请求客户端调用 MCP 工具。DevoxxGenie 内置了人工介入机制,并将请求您的批准。
点击批准按钮

点击"批准"按钮。MCP 服务器将执行 get_artists 工具,并将响应发送回 LLM。LLM 将使用此响应来给出适当的答案。

收到以下响应,并且完全正确。观察 LLM 的思维过程也很有趣。

<think> 好的,用户要求提供 Gunter 喜爱的艺术家列表。我调用了 `get_artists` 函数,返回了两位艺术家:Bruce Springsteen 和 JJ Johnson。现在他们可能想知道是否还有更多或者需要进一步帮助。

我应该确认结果,也许可以询问他们是否还需要其他什么。由于之前的响应是成功的,保持积极的语气很好。工具调用没有错误,所以这里不需要额外的函数调用。 </think>

以下是 Gunter 喜爱的艺术家:

*   **Bruce Springsteen**
*   **JJ Johnson**

如果您需要更多信息或帮助,请告诉我!

让我们使用以下提示检查 get_songs 工具:给我一个 Gunter 喜爱的歌曲列表

遵循相同的过程,响应再次正确。

<think> 好的,用户要求提供 Gunter 喜爱的歌曲列表。我使用了 get_songs 函数,它检索到了两首歌曲。现在我需要清晰地呈现这些信息。让我用艺术家和歌名来格式化每首歌曲。确保响应易于阅读,也许用项目符号。检查是否需要任何额外信息,但既然用户只想要一个列表,保持简单应该是最好的。 </think>

以下是 Gunter 喜爱的歌曲列表:

1.  **Bruce Springsteen** - *《My Hometown》*
2.  **JJ Johnson** - *《Lament》*

如果您想了解这些曲目的更多详细信息,请告诉我!

添加搜索功能

让我们向两个 MCP 工具添加一些基本的搜索功能。

ArtistService 添加一个 search_artist 工具。

@Tool(name = "search_artist", description = "从 Gunter 喜爱的艺术家中搜索单个艺术家")
public Artist getArtist(String name) {
    return artists.stream()
            .filter(artist -> artist.name().equalsIgnoreCase(name))
            .findFirst()
            .orElse(null);
}

SongService 添加一个 search_song 工具。

@Tool(name = "search_song", description = "从 Gunter 喜爱的歌曲中搜索单首歌曲")
public Song getSong(String title) {
    return songs.stream()
            .filter(song -> song.title().equalsIgnoreCase(title))
            .findFirst()
            .orElse(null);
}

构建 jar 文件并使用 DevoxxGenie 获取新工具。

输入以下提示:Bruce Springsteen 是 Gunter 喜爱的艺术家之一吗?

这次调用了 search_artist 工具,响应再次正确。

<think> 好的,用户询问 Bruce Springsteen 是否是 Gunter 喜爱的艺术家之一。我使用 search_artist 函数并传入了他的名字。响应返回了艺术家 "Bruce Springsteen"。现在我需要检查他是否在 Gunter 的喜爱列表中。

等等,可用的函数是 get_artists 和 search_artist。search_artist 函数可能检查艺术家是否存在于数据库中。既然响应返回了该艺术家,那意味着 Bruce Springsteen 确实在 Gunter 喜爱的艺术家列表中。

所以答案应该是肯定的。我应该根据函数的响应来确认这一点。既然用户的问题已经得到回答,不需要进一步的操作。只需清晰地呈现结果即可。 </think>

是的,Bruce Springsteen 是 Gunter 喜爱的艺术家之一。搜索确认了他在收藏中。

输入以下提示:滚石乐队是 Gunter 喜爱的艺术家之一吗?

调用了 search_artist 工具,由于未找到滚石乐队,LLM 断定他们不在我喜爱的艺术家列表中。

<think> 好的,让我试着弄清楚这里发生了什么。用户询问滚石乐队是否是 Gunter 喜爱的艺术家之一。我使用 search_artist 函数,传入了名称 "Rolling Stones",但响应是 null。这意味着该函数在 Gunter 的喜爱列表中没有找到该名称的艺术家。

嗯,也许数据库中艺术家的名称不完全是 "Rolling Stones"。会不会有拼写错误或不同的拼写方式?或者也许他们在系统中以另一个名称而闻名。或者,也许是因为数据不存在,所以函数没有返回任何结果。

既然用户是在询问 Gunter 的喜爱列表,我应该检查是否有一种方法可以首先列出所有喜爱的艺术家。get_artists 函数可能会有所帮助。如果我调用它,也许我可以看到滚石乐队是否在列表中。但是等等,用户可能不想要所有艺术家,只是确认这一个特定的。

或者,也许 search_artist 函数需要不同的参数。让我再次检查工具定义。search_artist 函数需要一个 "name" 参数,这是必需的。那么查询应该是大小写不敏感的?或者可能是部分匹配?用户可能指的是 "Rolling Stones",但数据库中的存储方式不同。

另一个想法:也许滚石乐队不在 Gunter 喜爱的艺术家列表中。搜索返回了 null,所以可能他们不在。但我应该通过先检查所有艺术家来确认。我应该向用户建议这一点。等等,但用户是专门询问滚石乐队。也许我应该告知他们搜索没有找到任何结果,并询问他们是否想改为检查所有艺术家。

等等,响应是 null,所以函数没有返回任何数据。这意味着该艺术家不在列表中。所以答案应该是否定的,滚石乐队不是 Gunter 喜爱的艺术家之一。但是函数调用会不会有错误?让我再检查一遍。函数是 search_artist,名称是 "Rolling Stones"。如果数据库中有确切的名称,那么它应该返回。如果没有,则返回 null。

所以结论是滚石乐队不在 Gunter 的喜爱列表中。或者,可能存在拼写错误。但既然用户是直接询问,我应该根据函数的响应来回答。 </think>

在 Gunter 喜爱的艺术家列表中,对艺术家 "Rolling Stones" 的搜索未返回任何结果。这表明滚石乐队**目前并未**列为 Gunter 喜爱的艺术家之一。您想改为查看他喜爱的艺术家的完整列表吗?

结论

在本博客中,您学习了如何使用 Spring Boot 和 Spring AI 创建一个 MCP 服务器。创建 MCP 服务器和添加工具非常容易。您可以专注于工具的功能,而这正是您想要的。


【注】本文译自:Creating an MCP Server With Spring AI

Java 缓存精要

Java 缓存精要

实现更低延迟、降低成本并赋能智能体架构

作者:GRANVILLE BARNETT
架构师,HAZELCAST

缓存技术在系统中的作用日益重要,对于大规模解锁众多用例至关重要。几十年来,缓存已实现低成本、可扩展地访问会话状态和数据存储等信息。更现代的缓存用例正在实现低成本、可扩展的工具链,并在智能体架构中实现嵌入生成,这正在解锁下一代系统创新。

本参考资料卡介绍了使用 Java 的 JCache(Java 临时缓存 API)将缓存融入系统的方法。文中首先讨论了缓存的基础知识,然后通过代码示例简要介绍了 JCache API,最后总结了缓存部署架构。

缓存概述

缓存是先前计算结果的一个存储,以便可以省略后续计算。理解缓存最简单的方式是将其视为键值存储:对于给定的输入(键),输出(值)代表先前基于该输入计算出的结果。

缓存命中表示特定数据存在于缓存中,这种情况下可以使用其值。否则,就会发生缓存未命中,此时需要执行相关计算并将其输出放入缓存。缓存未命中的代价可能除了昂贵的计算操作外,还涉及网络通信。

图 1:简化的缓存命中/未命中流程

采用缓存是为了减少延迟并降低运营成本,几十年来对于实现众多类别的应用程序至关重要。缓存数据的例子包括 Web 应用程序的会话状态、数据库查询结果、网页渲染结果,以及来自通用网络和计算成本高昂的操作的结果。

缓存的一个更现代的用途是在 AI 领域。在这里,缓存的使用减少了昂贵的 API 调用(例如,嵌入生成),并最大限度地减少了智能体架构中智能体之间的对话断续(例如,由于工具调用和网络通信所致),从而解锁了新一波的解决方案和用户体验。

缓存可以驻留在进程内,作为客户端-服务器架构的一部分存在于服务中,或者是两者的结合。此外,缓存的部署通常可以组合。例如,应用程序可能与位于同一数据中心的缓存服务通信,而数据中心的本地缓存又是跨越多个数据中心的缓存的缓存。这种灵活性,加上缓存所支持的应用类别,使得缓存在过去几十年中成为一种主导的抽象概念。

本参考资料卡的剩余部分将讨论 JCache——Java 用于将缓存融入应用程序的抽象——首先简要概述您将经常使用的类,然后深入探讨 JCache 更广泛功能所提供的特性。最后,我们将总结缓存部署策略。

JCACHE 精要

JCache 在 Java 规范请求(JSR)107 中引入,并提供了一套关于缓存的抽象。JCache 有两个突出的特性:

  • JCache 是一个规范。 JSR 是由专家组设计和提交,并最终由 Java 社区过程执行委员会批准的规范。因为 JCache 是一个规范,所以它与那些 API 频繁变化的实现隔离开来。
  • JCache 是提供商独立的。 JCache 作为规范的一个副作用是,缓存解决方案提供商可以通过实现其暴露的服务提供程序接口(SPI)来与 JCache 集成。这为系统设计者提供了灵活性并避免了供应商锁定。

以下是一个简单的 JCache 示例,以便理解其使用方式。javax.cache 依赖项的获取方式可以在此处找到。

import java.util.Map;
import javax.cache.Cache;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.cache.configuration.MutableConfiguration;
import javax.cache.spi.CachingProvider;

public class App {
    public static void main(String[] args) {
        CachingProvider cachingProvider = Caching.getCachingProvider(); // (1)
        CacheManager cacheManager = cachingProvider.getCacheManager(); // (2)
        MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>(); // (3)
        Cache<String, String> cache = cacheManager.createCache("dzone-cache", cacheConfig); // (4)
        cache.put("England", "London"); // (5)
        cache.putAll(Map.of("France", "Paris", "Ireland", "Dublin")); // (6)
        assert cache.get("England").equals("London"); // (7)
        assert cache.get("Italy") == null; // (8)
    }
}

对上述示例的简要说明:
(1) 获取底层缓存提供程序的句柄
(2) 管理缓存的生命周期(例如,创建和销毁缓存)
(3) 允许启用/禁用缓存的特定功能(例如,统计信息、条目监听器)
(4) 创建由缓存提供程序支持的缓存
(5) 在缓存中放入单个键值条目
(6) 将键值条目放入缓存
(7) 断言缓存条目的存在
(8) 断言某个条目不在缓存中

本节的剩余部分将更详细地讨论上述示例中引入的抽象,以及您将经常遇到的相关类的其他方法。

javax.cache.spi.CachingProvider 构成了 JCache SPI,缓存提供者可以与之集成。您将使用的最常见功能是获取对 CacheManager 的引用。我们稍后将讨论 Caching

getCacheManagergetCacheManager 变体中最简单的一个。这将根据提供者的默认设置获取一个 CacheManager。可以使用 javax.cache.CacheManager 创建和销毁缓存:

  • createCache 创建一个具有给定名称和配置的缓存。
  • destroyCache 销毁具有给定名称的缓存。

javax.cache.Cache 是对提供者缓存的抽象,并暴露了少量用于查询和变更缓存项的操作:

  • putputAll 将条目放入缓存。请注意,这些方法不返回与正在放入的键先前关联的任何值。
  • containsKey 测试键是否存在于缓存中。
  • getgetAll 返回与指定键关联的值。
  • removeremoveAll 从缓存中移除项。

JCACHE 包

在本节中,我们将快速概述 javax.cache 更广泛包结构中的一些重要接口,并提供常用功能的示例。我们可以参考文档来浏览其内容的详尽列表。

图 2:javax.cache 的组成包

JAVAX.CACHE

通用管理(CacheManager)和与缓存交互(Cache)的设施位于 javax.cache 包内。除了初始配置之外,除非您想为缓存添加额外功能,否则仅使用此包中的类型就可以完成很多工作。例如,"JCache 精要"部分介绍中的示例用法主要使用了 javax.cache 中定义的接口。

JAVAX.CACHE.CONFIGURATION

在创建缓存期间,您可能希望添加功能,例如启用统计信息或通读缓存。此包提供了一个 Configuration 接口和一个实现 MutableConfiguration,可用于此类目的。

// ...
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
cacheConfig.setManagementEnabled(true).setStatisticsEnabled(true);
Cache<String, String> cache = cacheManager.createCache("dzone-cache", cacheConfig);

JAVAX.CACHE.EXPIRY

有时您希望驻留在缓存中的项过期。例如,我们可能有一个家庭保险报价的缓存,有效期为 24 小时。在这种情况下,我们可以使用过期策略如下:

// ...
MutableConfiguration<String, Double> cacheConfig = new MutableConfiguration<String, Double>();
cacheConfig.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ONE_DAY));
Cache<String, Double> cache = cacheManager.createCache("insurance-home-quotes", cacheConfig);
cache.put(quote.getId(), quote.getValue());

javax.cache.expiry 包提供了额外的过期策略,可能对其他场景有用。例如,AccessedExpiryPolicy 允许基于缓存条目的最后访问时间附加过期设置。

JAVAX.CACHE.EVENT

JCache 的一个强大功能是能够订阅缓存事件。例如,我们可能希望在创建或删除缓存条目后运行某些领域逻辑。javax.cache.event 包提供了实现此功能的抽象,特别是订阅缓存创建、更新、过期和移除的能力。以下基本示例在缓存条目创建后运行某些领域逻辑:

// ...
CacheEntryCreatedListener<String, String> createdListener = new CacheEntryCreatedListener<String, String>() {
  @Override
  public void onCreated(Iterable<CacheEntryEvent<? extends String, ? extends String>> events) throws CacheEntryListenerException {
    for (var c : events) {
      performDomainLogic(c);
    }
  }
};
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
MutableCacheEntryListenerConfiguration<String, String> listenerConfig = new MutableCacheEntryListenerConfiguration<>(() -> createdListener, null, false, true); // 请参阅文档
cacheConfig.addCacheEntryListenerConfiguration(listenerConfig);
Cache<String, String> cache = cacheManager.createCache("events", cacheConfig);
cache.put("key", "value"); // 调用创建监听器

JAVAX.CACHE.PROCESSOR

JCache 的一个强大组件是能够使用 EntryProcessor 将计算移至数据所在处,然后以编程方式调用该计算。当使用在分布式系统(例如,Hazelcast)内托管其缓存的提供者时,这尤其强大,因为它以很少的投入为分布式计算提供了一个简单的入口点。以下是一个 EntryProcessor 的简单示例,它将 UUID 附加到缓存条目:

// ...
class AppendUuidEntryProcessor implements EntryProcessor<String, String, String> {
  @Override
  public String process(MutableEntry<String, String> entry, Object... arguments) throws EntryProcessorException {
    if (entry.exists()) {
      String newValue = entry.getValue() + "-" + UUID.randomUUID();
      entry.setValue(newValue);
      return newValue;
    }
    return null;
  }
}
// ...
cache.invoke(key, new AppendUuidEntryProcessor())

JAVAX.CACHE.MANAGEMENT

JCache 提供的管理钩子非常强大且易于启用。例如,下面的小代码片段暴露了由 Java 管理扩展(JMX)规范定义的托管 Bean。这使得诸如 jconsole 和 JDK Mission Control 之类的 JMX 客户端能够查看缓存配置和统计信息(例如,命中和未命中百分比、平均获取和放置时间)。

// ...
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
cacheConfig.setManagementEnabled(true).setStatisticsEnabled(true);
Cache<String, String> cache = cacheManager.createCache("management", cacheConfig);
// ...

JAVAX.CACHE.SPI

"JCache 精要"部分提供的示例省略了我们如何注册缓存提供者,即使用 JCache API 与我们的应用程序交互的缓存宿主服务。这就是 JCache 的 SPI 组件发挥作用的地方。

实现这一点有两个组成部分:

  1. 将我们的缓存提供者添加到类路径中
  2. 告诉 JCache 使用该提供者

第一步很简单:只需添加对任何符合 JSR 107 标准的提供者的依赖。

第二步有几种通用的方法:

  • 我们可以通过调用 Caching#getCachingProvider(...) 的某个变体(以及其他方法)来告诉 JCache。
  • 我们可以提供一个 META-INF/services/javax.cache.spi.CachingProvider 文件,并让其指定提供者实现。指定的提供者是您的提供者的缓存提供者实现的完全限定名称。
  • 我们可以使用 Caching#getCachingProvider();但是,最好明确限定要使用的提供者,因为您的类路径上可能有多个提供者,这会抛出 javax.cache.CacheException

例如,以下代码使用 CachingProvider Caching.getCachingProvider(String) 指定 Hazelcast 为提供者:

CachingProvider cachingProvider = Caching.getCachingProvider("com.hazelcast.cache.HazelcastCachingProvider");
CacheManager cacheManager = cachingProvider.getCacheManager();
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
Cache<String, String> cache = cacheManager.createCache("spi-example", cacheConfig);
cache.put("k", "v");

JAVAX.CACHE.ANNOTATION

JCache 定义了许多注解,用于集成到上下文和依赖注入环境中。Spring Framework 原生支持 JCache 注解。我们可以参考 JCache 文档以获取更多信息。

JAVAX.CACHE.INTEGRATION

javax.cache.integration 包提供了 CacheLoader(需要通读)和 CacheWriter(需要通写)。CacheLoader 在将数据读入缓存时使用——例如 Cache#loadAll(...)CacheWriter 可以作为一个集成点,将缓存变更(例如,写入、删除)传播到外部存储服务。

缓存部署

JCache 没有缓存部署策略的概念;它仅仅是缓存提供者之上的一个 API。然而,不同的提供者支持不同类型的缓存部署。请考虑哪种缓存部署对您的应用程序有意义,并由此反向确定合适的缓存提供者。

图 3: 缓存部署示例

请注意,一些缓存提供者可能支持所有这三种缓存部署,而其他提供者可能不支持。

本节的剩余部分讨论图 2 中所示的常见缓存部署:

  • 嵌入式 – 缓存与应用程序位于同一进程中。
  • 客户端-服务器 – 缓存托管在独立的服务中,客户端与该服务通信以确定缓存驻留。
  • 嵌入式/客户端-服务器 – 这是一种混合模式,整个缓存托管在不同的服务上,但客户端在同一进程中拥有一个较小的本地缓存。

重要的是要注意,上述缓存部署并非互斥的;它们可以通过多种方式组合以满足应用程序需求。

最简单的缓存部署是让缓存与应用程序驻留在同一进程中,这样做的好处是提供低延迟的缓存访问。嵌入式缓存不能在应用程序之间共享,并且在应用程序重启或故障时,其托管(它们所需的资源)和重建成本可能很高。

客户端-服务器缓存部署将缓存托管在与客户端不同的服务中。缓存服务允许通过跨服务复制来满足容错需求,提供更大的容量、更多的可扩展性选项,以及跨应用程序共享缓存的能力。客户端-服务器模型的主要缺点在于客户端缓存查询期间网络通信的成本。

混合嵌入式/客户端-服务器部署是指我们拥有一个嵌入式缓存,它包含来自服务缓存条目的一个子集,作为应用程序缓存请求的副作用被填充。在这里,客户端可以对频繁访问的数据(或表现出特定访问模式的数据)实现低延迟的缓存命中,并省去与缓存服务通信所带来的网络通信开销。如果嵌入式缓存过期,一些提供者会负责使用服务托管的缓存来更新它们。

结论

本参考资料卡介绍了缓存以及如何将其与 Java 的 JCache API 一起使用。JCache API 直观、强大,并且由于其是一个规范而避免了供应商锁定,为架构师和系统设计者提供了他们所需的灵活性。这种灵活性在我们进入基于智能体架构的新一代创新时尤为重要,其中缓存对于工具链和嵌入生成至关重要。

作者:GRANVILLE BARNETT,
架构师,HAZELCAST
Granville Barnett 拥有计算机科学博士学位,是拥有超过 15 年经验的分布式系统专家。他目前是 Hazelcast 的架构师,此前曾在 HP Labs 和 Microsoft 任职。Granville 拥有多项美国专利,并发表了关于程序验证主题的研究。

附加资源:


【注】本文译自:Java Caching Essentials