[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为我们的工作感到无比自豪,并遵循最佳实践以确保内容的准确性,为我们的订阅者提供愉悦的阅读体验。我们的读者是我们的镜子,我们利用他们的反馈来反思并改进出版过程中可能发生的人为错误。为了让我们保持质量并帮助联系到因任何未预见错误而遇到困难的读者,请写信至:[email protected]
BPB Publications家族非常感谢您的支持、建议和反馈。
在 www.bpbonline.com,您还可以阅读免费技术文章集,注册各种免费时事通讯,并享受BPB书籍和电子书的独家折扣和优惠。您可以在下面查看我们的社交媒体账号:
盗版
如果您在互联网上以任何形式遇到我们作品的非法复制品,若能提供其地址或网站名称,我们将不胜感激。请通过 [email protected] 联系我们,并附上材料链接。
如果您有兴趣成为作者
如果您是某个领域的专家,并且有兴趣撰写或贡献一本书,请访问 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 中应用领域驱动设计:一种行为驱动方法

了解如何结合 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