Java战术领域驱动设计入门：构建语义化代码的步骤

现代软件系统很少因编码能力不足而失败。多数失败发生在团队偏离了所要解决的业务问题时。随着系统演进、需求变化、团队扩张、新集成添加，代码库往往成为缺乏业务背景的技术决策集合。类变成泛泛的管理器和服务，方法退化为过程式脚本，开发人员与领域专家之间的沟通逐渐减少。战术领域驱动设计（DDD）通过强调软件直接在代码中反映业务语言，而非仅仅关注基础设施或框架，来解决这一问题。

“语义”一词源于希腊语semantikos，意为“有意义的”或“含义丰富的”，这正是指挥战术DDD的核心。目标不仅是重组类，而是要确保代码能向工程师和业务专家清晰传达意图。在现代Java系统中，由于分布式架构、集成和持续的业务变化而带来的复杂性，这种清晰性对于长期可维护性至关重要。

战术DDD提供了实体、值对象、聚合、仓库、工厂和领域服务等实用模式，以保留代码库的含义并管理复杂性。本文将使用Java和足球锦标赛场景，逐步剖析这些模式，展示语义代码如何提升系统的理解、演进和维护能力。

实体

在应用战术DDD模式之前，重要的是认识到它们不应成为设计过程的起点。软件项目中的一个常见错误是在未理解业务之前就开始构建实体、仓库和聚合。战术模式是实施工具，而非发现工具。战略DDD应从定义领域边界、通用语言和业务上下文开始。只有在理清问题空间之后，才能使用战术模式将理解转化为代码。

实体是核心的战术DDD模式。该术语源自拉丁语ens，意为“存在物”。在软件设计中，它指的是在其生命周期中保持身份的对象。实体并非由其当前属性定义，而是由业务在不同时间点上将其视为同一个概念对象来定义。当领域必须跟踪对业务重要的某个对象的生命周期时，实体非常有用。

在足球锦标赛中，球员是实体的一个明显例子。球员在职业生涯中可能更换球队、位置、薪水或统计数据，但系统会持续将其识别为领域内的同一个个体。因此，身份比属性变化更为重要。以下Java类说明了这一概念：

import java.util.UUID;

public class Player {
    private UUID id;
    private String name;
    private Position position;

    public Player(UUID id, String name, Position position) {
        this.id = id;
        this.name = name;
        this.position = position;
    }
}

Player类通过在id字段中使用唯一标识符来演示实体模式。该标识符使应用程序能够区分不同的球员，无论其他属性如何变化。虽然name和position可能改变，但身份保持不变。这一特性将该对象定义为实体，而非简单的数据结构或值对象。

值对象

实体由身份定义，但并非所有领域概念都需要生命周期跟踪或唯一标识。许多业务概念描述的是特征、度量、分类或不可变的含义。值对象模式就是针对这些情况而设计的。在这里，“值”意味着对象完全由其属性定义，而非身份。在战术DDD中，值对象减少了对原始类型的依赖，并澄清了代码库中的领域语言。

值对象是一个不可变对象，表示领域的描述性方面。与实体不同，两个具有相同值的值对象被视为相同。值对象常用于货币、地址、坐标、状态、度量或分类等概念。其主要目的是提高语义清晰度，并为特定概念封装领域规则。

在足球锦标赛场景中，球员位置是值对象的一个好例子，因为应用程序不需要跟踪其生命周期。领域只关心值的含义。以下Java枚举说明了这一概念：

public enum Position {
    GOALKEEPER, DEFENDER, MIDFIELDER, FORWARD
}

Position枚举通过表示业务分类而非在整个代码库中使用原始字符串，应用了值对象模式。通过使用显式类型而非原始文本（如“forward”或“goalkeeper”），应用程序提高了可读性，减少了无效状态，并强化了开发人员与领域专家之间的共享语言。

工厂

随着领域模型的发展，对象创建常常需要比调用构造函数更多的工作。业务规则、验证、默认值和初始化步骤可能散落在控制器、服务或应用层中，导致重复和领域知识碎片化。工厂模式将对象创建集中化，确保新的领域对象是有效且有意义的。

工厂是一种战术DDD模式，它封装了实体或聚合的创建逻辑。其目的不仅仅是“隐藏构造函数”，而是在对象创建过程中表达领域意图。工厂源自制造业，确保对象在投入使用前正确组装。在软件中，这种方法在实例化过程中保持了一致性并强制执行了业务规则。

在足球锦标赛场景中，创建一名球员需要分配内存之外的工作。一名新的前锋球员必须具有正确的位置和唯一的身份。将这一逻辑集中到工厂中，可以防止系统中出现重复。

import java.util.UUID;

public class PlayerFactory {
    public Player createFoward(String name) {
        return new Player(
            UUID.randomUUID(),
            name,
            Position.FORWARD
        );
    }
}

PlayerFactory通过封装Player创建的细节实现了工厂模式。应用层无需管理标识符生成或前锋球员的位置分配。方法名称传达了业务意图，使代码表达有意义的领域操作，而不是低层次的构造细节。

聚合根

随着系统规模的增长，维护相关实体之间的一致性变得更具挑战性。没有清晰的边界，业务规则可能会蔓延到服务、仓库和事务中。战术DDD通过在领域模型内定义显式的一致性边界来解决这一问题。聚合和聚合根模式对此至关重要。

聚合是一组作为单一一致性边界管理的相关实体和值对象。聚合根作为主要入口点，协调并保护聚合的内部状态。在实践中，聚合根确保在状态变更期间进行受控修改并维护业务规则的一致性。

在足球锦标赛场景中，球队通过管理其球员的生命周期和一致性来充当聚合根。应用程序不应直接修改球员集合；所有变更都应通过球队定义的接口进行：

import java.util.Collections;
import java.util.List;

public class Team {
    private TeamId id;
    private String name;
    private List<Player> players;

    public Team(TeamId id, String name, List<Player> players) {
        this.id = id;
        this.name = name;
        this.players = players;
    }

    public List<Player> getPlayers() {
        return Collections.unmodifiableList(players);
    }

    public void remove(Player player) {
        players.remove(player);
    }

    public void add(Player player) {
        players.add(player);
    }
}

Team类实现了聚合根模式，管理对其球员集合的访问。它不允许多直接修改，而是提供add和remove方法。这使得业务规则得以演进，并确保了整个应用程序的一致性。聚合根守护着领域边界并维护着生命周期。

仓库

企业应用中最大的挑战之一是避免业务逻辑与持久化关注点之间的紧密耦合。随着时间的推移，SQL查询、数据库操作、缓存逻辑和基础设施细节可能渗入领域层，使代码更难维护和演进。战术DDD通过仓库模式解决了这个问题，该模式为管理聚合提供了类似集合的抽象。

“仓库”一词源自拉丁语repositorium，意为“存储物品的地方”。在领域驱动设计中，仓库不仅仅是DAO或用于执行查询的工具类。其主要目标是提供对聚合的访问，同时向领域模型隐藏基础设施的复杂性。仓库允许应用程序使用领域概念而非持久化机制，从而保持业务逻辑与技术实现之间的分离。

在足球锦标赛场景中，应用程序需要一种机制来持久化和检索球队，同时不向业务流暴露数据库细节。由于Team充当聚合根，仓库负责将其作为一致性边界进行管理：

public interface TeamRepository {
    Team save(Team team);
}

TeamRepository通过将持久化操作抽象在领域导向的契约背后，应用了仓库模式。应用层无需知道数据是存储在PostgreSQL、MongoDB、Redis还是其他技术中。更重要的是，仓库通过聚合本身直接传达了业务意图。代码操作的是有意义的领域概念（如Team），而非表或记录，从而保持了模型的语义清晰度并减少了领域与基础设施层之间的耦合。

领域服务

并非所有业务操作都适合放在实体或聚合根中。随着领域的发展，一些规则涉及多个实体或不属于单个对象的协调逻辑。将这些责任分配给实体可能导致模型臃肿和内聚性降低。战术DDD通过领域服务模式解决了这一问题。

领域服务包含不属于特定实体或值对象但仍属于领域模型的业务逻辑。其作用是执行涉及多个领域对象的有意义的业务操作，而非处理技术编排或基础设施。在DDD中，服务在保持模型清晰性的同时封装跨聚合的领域行为。

在足球锦标赛场景中，球员在球队之间转会涉及多个聚合的业务操作。该责任并不单独属于球员或单个球队。相反，该操作代表了协调源球队和目标球队的领域行为：

public class TransferService {
    public void transfer(
            Player player,
            Team source,
            Team destination) {
        source.remove(player);
        destination.add(player);
    }
}

TransferService通过封装球员在球队之间转会的业务逻辑实现了领域服务模式。该服务直接表达了领域概念，而不是将逻辑分散到控制器或应用层。该方法使用领域的通用语言清晰地传达了业务意图。代码现在反映的是开发人员和业务专家都能识别的有意义操作：在锦标赛生命周期中转会球员。

领域事件

在复杂系统中，重要的业务行为很少只影响应用程序的单一部分。一个领域中的变更经常触发其他上下文中的反应，例如通知、分析、集成、审计或外部工作流。直接耦合这些关注点会导致僵化的架构，其中每个新需求都会增加跨系统的依赖关系。战术DDD通过领域事件模式应对这一挑战。

领域事件代表业务领域中已经发生的重要事件。强调过去时态是刻意的，因为事件描述的是事实，而非命令或意图。“事件”一词源自拉丁语eventus，意为“结果”或“发生”。在领域驱动设计中，领域事件允许系统在减少组件与限界上下文之间耦合的同时，沟通有意义的业务变更。领域发布事件，系统的其他部分可以独立地对此做出反应，而不是直接调用每个依赖操作。

在足球锦标赛场景中，签下一名新球员是系统其他部分可能关心的一个重要业务事件。锦标赛可能想要通知球迷、更新统计数据、触发商品销售活动或与外部系统同步。不是将所有责任直接嵌入转会逻辑中，而是应用程序可以通过领域事件显式地表示该发生：

public record NewSoccerHired(
        Team team,
        Player player) {
}

然后，在业务操作成功完成后发布该事件：

eventPublisher.publish(
    new NewSoccerHired(destination, player)
);

NewSoccerHired记录通过表示领域模型内有意义的业务事实，应用了领域事件模式。系统不再紧密耦合多个责任，而是暴露一个语义上的业务发生，架构的其他部分可以独立地对此做出反应。这种方法提高了可扩展性，减少了直接依赖关系，并在应用程序生命周期中保留了通用语言。

应用服务

随着系统的演进，业务操作通常需要跨领域组件、持久化点和集成点进行协调。没有清晰的编排层，这种逻辑可能会蔓延到控制器、API和基础设施类中，导致紧密耦合、难以维护的应用程序。战术DDD通过应用服务模式解决了这一问题。

应用服务编排用例并协调领域操作。与封装业务规则的领域服务不同，应用服务管理业务动作的执行流程。在DDD中，它充当协调层，连接仓库、领域操作和外部交互，同时保持领域模型专注于业务行为。

在足球锦标赛场景中，球员在球队之间转会需要的不仅是一个业务规则。该操作协调转会逻辑、持久化和事件发布。以下类将这种编排集中到一个用例中：

public class TransferPlayerUserCase {
    private final TeamRepository teamRepository;
    private final TransferService transferService;
    private final EventPublisher eventPublisher;

    public TransferPlayerUserCase(
            TeamRepository teamRepository,
            TransferService transferService,
            EventPublisher eventPublisher) {
        this.teamRepository = teamRepository;
        this.transferService = transferService;
        this.eventPublisher = eventPublisher;
    }

    public void execute(
            Player player,
            Team source,
            Team destination) {
        transferService.transfer(player, source, destination);
        teamRepository.save(source);
        teamRepository.save(destination);
        eventPublisher.publish(
            new NewSoccerHired(destination, player)
        );
    }
}

TransferPlayerUserCase通过编排整个球员转会过程演示了应用服务模式。该类将编排逻辑放在一个单一工作流中，而不是放在控制器或实体中，从而协调领域操作、持久化和事件发布。该方法代表了领域内有意义的业务行为：在锦标赛期间将球员在球队之间转会。

结论

战术领域驱动设计并非旨在增加不必要的复杂性或盲目应用模式。其目的是帮助工程师构建通过代码清晰传达业务意义的软件。通过引入实体、值对象、工厂、聚合、仓库、领域服务、领域事件和应用服务等概念，开发人员可以创建更易于理解、维护和适应业务需求变化的系统。战术DDD还弥合了技术与业务视角之间的差距，使代码成为领域的语义表征。

本文使用Java和足球锦标赛场景介绍了核心的战术DDD模式。目的并非涵盖领域驱动设计的方方面面，而是展示这些模式如何帮助构建表达性强且可维护的系统。随着项目变得越来越复杂，在代码库中保留业务意义变得越来越重要，尤其是在现代分布式架构中，技术复杂性可能掩盖领域语言。

视频3

DZone贡献者表达的观点属于他们自己。