DDD实践：如何合理设计值对象与处理复杂数据结构

在领域驱动设计（DDD）中，值对象（Value Object）是核心概念之一，用于封装具有概念整体性但无独立标识的属性。本文旨在提供一份实践指南，探讨如何在复杂的业务场景下，平衡DDD原则与实际开发效率，合理设计值对象的粒度，避免过度工程化。同时，将深入分析如何处理多表关联数据，确保实体（Entity）构建的清晰性与领域边界的完整性。

理解值对象与粒度设计

值对象是DDD中的一个重要构建块，它描述了领域中的某个概念性方面，但没有唯一的标识符。例如，一个地址（Address）可以由街道、城市、邮政编码等组成，它作为一个整体有意义，但我们通常不关心某个特定的地址实例，只关心它的值。

在实践中，关于值对象的粒度，一个常见的困惑是：是否每个数据表字段都应该对应一个值对象？对于一个包含60个字段的表，如果为每个字段都创建独立的值对象，可能会导致严重的过度工程化。以下是设计值对象粒度的几个关键考量：

1. 概念整体性： 值对象应代表一个有意义的、不可分割的概念单元。例如，Street、City、PostalCode单独可能只是字符串，但组合成Address就有了明确的领域含义和行为（如格式化地址、比较地址是否相同）。
2. 领域行为： 如果某个属性或一组属性具有特定的领域行为（例如，一个Email值对象可以包含isValid()方法来验证邮箱格式），那么将其封装为值对象是合理的。如果一个字段仅仅是存储数据，没有特殊的业务规则或行为，将其作为原始类型（如字符串、整数）直接在实体中使用可能更为简洁。
3. 避免过度工程化： 并非所有字段都需要成为值对象。过度细化的值对象会增加代码复杂性，降低可读性，并且可能不会带来额外的领域价值。在决定是否创建值对象时，应权衡其带来的好处（如类型安全、行为封装、领域表达力）与成本（如代码量、维护难度）。

示例： 考虑一个用户表，其中包含id、first_name、last_name、email、street、city、postal_code等字段。

• UserId：通常作为实体标识符，可以封装为值对象，提供唯一性保证。
• Email：可以封装为值对象，包含邮箱格式验证逻辑。
• Address：由street、city、postal_code组成，作为一个整体封装为值对象，提供地址相关的行为。
• FirstName、LastName：如果它们没有复杂的业务规则或行为，可以直接作为字符串处理，或组合成一个FullName值对象（如果存在如getFormalName()等行为）。

<?php

// 示例：值对象定义
final class UserId
{
    private string $id;

    public function __construct(string $id)
    {
        if (empty($id)) {
            throw new InvalidArgumentException('User ID cannot be empty.');
        }
        $this->id = $id;
    }

    public function value(): string
    {
        return $this->id;
    }

    public function equals(UserId $other): bool
    {
        return $this->id === $other->id;
    }
}

final class Email
{
    private string $email;

    public function __construct(string $email)
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('Invalid email format.');
        }
        $this->email = $email;
    }

    public function value(): string
    {
        return $this->email;
    }

    public function equals(Email $other): bool
    {
        return $this->email === $other->email;
    }
}

final class Address
{
    private string $street;
    private string $city;
    private string $postalCode;

    public function __construct(string $street, string $city, string $postalCode)
    {
        if (empty($street) || empty($city) || empty($postalCode)) {
            throw new InvalidArgumentException('Address components cannot be empty.');
        }
        $this->street = $street;
        $this->city = $city;
        $this->postalCode = $postalCode;
    }

    public function getStreet(): string
    {
        return $this->street;
    }

    public function getCity(): string
    {
        return $this->city;
    }

    public function getPostalCode(): string
    {
        return $this->postalCode;
    }

    public function fullAddress(): string
    {
        return sprintf('%s, %s, %s', $this->street, $this->city, $this->postalCode);
    }

    public function equals(Address $other): bool
    {
        return $this->street === $other->street &&
               $this->city === $other->city &&
               $this->postalCode === $other->postalCode;
    }
}

// 示例：实体定义
class User
{
    private UserId $id;
    private string $firstName; // 简单字符串，无复杂行为
    private string $lastName;  // 简单字符串，无复杂行为
    private Email $email;
    private Address $address;

    public function __construct(
        UserId $id,
        string $firstName,
        string $lastName,
        Email $email,
        Address $address
    ) {
        $this->id = $id;
        $this->firstName = $firstName;
        $this->lastName = $lastName;
        $this->email = $email;
        $this->address = $address;
    }

    public function getId(): UserId
    {
        return $this->id;
    }

    public function getFirstName(): string
    {
        return $this->firstName;
    }

    public function getLastName(): string
    {
        return $this->lastName;
    }

    public function getEmail(): Email
    {
        return $this->email;
    }

    public function getAddress(): Address
    {
        return $this->address;
    }

    // 实体行为示例
    public function updateAddress(Address $newAddress): void
    {
        $this->address = $newAddress;
    }
}

登录后复制

处理多表关联与领域边界

在DDD中，处理多表关联数据是一个需要谨慎对待的问题，尤其是在涉及到跨越不同聚合根或有界上下文（Bounded Context）的数据时。将20个关联表的数据都视为一个实体的一部分，并尝试在实体构建时通过SQL JOIN全部加载，这通常与DDD的理念相悖。

1. 有界上下文（Bounded Context）： DDD强调将大型系统划分为多个有界上下文，每个上下文都有自己的通用语言、模型和数据。一个表可能在一个上下文中是核心实体，但在另一个上下文中可能只是一个值对象或辅助数据。
2. 聚合根（Aggregate Root）： 聚合根是DDD中数据修改和一致性的边界。一个聚合根通常只包含其直接相关的实体和值对象。当需要修改数据时，只能通过聚合根进行操作。将过多不相关的表数据加载到一个实体中，会使聚合根变得臃肿，难以维护，并可能破坏一致性。
3. 数据访问策略：
   • 一个聚合一个仓库（Repository）： 每个聚合根应该有一个专门的仓库来负责其持久化和检索。仓库的职责是提供聚合根的完整实例，而不是将多个不相关的聚合或数据源连接起来。
   • 避免跨上下文的SQL JOIN： 如果20个表代表了不同的业务概念或属于不同的有界上下文，不应该在SQL层面进行大范围的JOIN来构建一个单一的实体。这会导致紧耦合，并模糊领域边界。
   • 按需加载： 如果某个实体需要来自其他上下文的数据，可以通过领域服务（Domain Service）或应用服务（Application Service）在运行时按需获取，而不是在实体构建时一次性加载所有。例如，一个Order聚合可能需要Product的信息，但Product是Catalog上下文的聚合。Order聚合不会直接包含Product实体，而是通过ProductId引用，并在需要时通过CatalogService获取Product详情。
   • 读模型（Read Model）： 对于复杂的查询和报表需求，可以考虑使用读模型（或查询模型），它们是专门为查询优化而设计的，可以自由地进行JOIN操作，而无需遵循DDD的写入模型限制。

注意事项：

标签： php 编码 app ai 邮箱 数据访问 gate