DDD与TDD（2024）

辞暮尔尔-烟火年年

已于 2024-01-31 11:52:19 修改

阅读量1.6k

点赞数 33

分类专栏：微服务复习面试专栏文章标签： tdd java 服务器

于 2024-01-15 09:22:10 首次发布

本文链接：https://blog.csdn.net/qq_43012298/article/details/135581099

版权

复习面试专栏同时被 2 个专栏收录

56 篇文章 12 订阅

订阅专栏

微服务

51 篇文章 0 订阅

订阅专栏

什么是领域驱动设计（DDD）？

领域驱动设计（Domain-Driven Design，简称DDD）是一种软件开发方法，旨在通过深入理解业务领域（Domain）的复杂性，创建有效且富有表现力的软件模型。这种方法由Eric Evans在其2004年出版的书《领域驱动设计：软件核心复杂性应对之道》中详细介绍。

DDD的核心在于业务领域和业务逻辑的重要性，它结合了一系列概念、原则和模式，并鼓励开发人员、业务分析师和业务专家之间的紧密合作。

DDD的关键概念包括：

Ubiquitous Language（泛在语言）：
泛在语言是团队成员用于沟通领域模型的共同语言。这种语言在团队成员之间共享，确保在讨论软件及其功能时避免歧义和混淆。
限界上下文（Bounded Context）：
限界上下文是领域中明确边界内的模型。每个限界上下文内部都有一致性和完整性，它定义了模型适用的特定范围，不同的限界上下文可以用不同的模型来表示同一领域的不同部分。
实体（Entity）和值对象（Value Object）：
实体是拥有唯一标识符和生命周期的域对象，它的身份不会因其属性的改变而改变。值对象则是无需唯一标识符、通过其属性完全定义、通常是不可变的域对象。
聚合（Aggregate）和聚合根（Aggregate Root）：
聚合是一组关联对象的集合，它们被看作是一个单元用于数据修改。聚合根是聚合的一个实体，它充当了聚合的入口，负责保证聚合的完整性和不变性。
领域服务（Domain Service）：
领域服务包含特定领域内的操作和业务逻辑，这些操作不自然属于任何实体或值对象，因此被封装在服务中。
应用服务（Application Service）：
应用服务协调领域层和应用程序的其他部分，如用户界面或外部接口。它们定义了软件的用例和操作，但不包含业务规则。
领域事件（Domain Event）：
领域事件是在域模型中发生的、对业务来说具有意义的事件。它们是不可变的，用于表示某些事情已经发生，并可以触发业务流程中的其他操作。
仓储（Repository）：
仓储为聚合或实体提供了持久化机制。它抽象了底层存储和获取聚合的细节，并提供了集合式的接口来管理领域对象。

DDD的实施步骤：

深入理解业务：
与业务专家合作，深入探讨领域知识，确保软件反映真实的业务需求。
创建和维护模型：
建构领域模型，这个模型应该是丰富的、表达力强的，并且是反映业务理解的实体、值对象、服务和事件的集合。
发展泛在语言：
开发和业务团队应共同演进泛在语言，确保模型和语言随着业务的发展而发展。
定义限界上下文：
识别并定义模型的边界，以维护模型内的一致性，并管理不同上下文间的集成。
打磨模型：
模型不是一成不变的，需要随着业务的发展和团队理解的提升而不断演化。
集成和测试：
确保模型的实现正确无误，并且能有效地与系统的其他部分集成。

DDD的目标是通过创建一个紧密映射业务领域的模型来简化软件开发，提高软件质量，并使得软件能够持续适应业务的变化。通过将关注点集中在核心领域，DDD可以帮助团队避免不必要的复杂性，并构建更加灵活、可维护的系统。

贫血模型

贫血模型（Anemic Domain Model）是一种软件开发模型，这个名词通常在领域驱动设计（DDD）的讨论中被提及，用于描述那些领域模型中缺乏业务逻辑的情况。在贫血模型中，领域对象（通常是实体和值对象）仅仅包含数据状态，而没有相应的行为，这意味着它们更像是数据结构或数据传输对象（Data Transfer Objects，DTOs），而业务逻辑则被放置在服务层中，通常是以一系列的服务类来实现。

贫血模型的特点：

数据与行为分离：
领域实体包含数据字段，但不包含业务规则或行为。所有的业务逻辑都是由外部的服务层处理的。
低内聚力：
由于数据和行为的分离，领域实体本身无法保证自身业务规则的一致性，因此这些实体通常被视作低内聚力的。
过度依赖服务层：
业务逻辑主要集中在服务层，这导致领域模型依赖于服务层才能实现业务功能。
过度使用数据传输对象（DTO）：
在远程通信或界面显示时，常常需要使用DTO来传递数据，DTO的过度使用可能会导致模型的复杂性增加。

贫血模型的问题：

违反面向对象设计原则：
根据面向对象设计原则，数据和行为应该被封装在一起。贫血模型的做法破坏了封装性，因为数据和行为是分离的。
复杂的服务层：
所有业务逻辑都集中在服务层，这可能导致服务层变得复杂而难以维护。
代码重用性差：
由于领域实体中缺乏行为，所以难以在不同的上下文中重用这些实体。
测试难度增加：
对于业务逻辑的测试通常需要在服务层进行，这可能导致测试更加复杂。
困难的维护和演化：
随着业务逻辑的增长，服务层可能会变得越来越庞大，难以分析和修改。

与充血模型的对比：

充血模型（Rich Domain Model）是一个包含数据和行为的领域模型，它是DDD推荐的模型。在充血模型中，实体和值对象包含了与之相关的业务逻辑，更加符合面向对象的原则。

使用场景：

尽管贫血模型有许多缺点，它在某些情况下仍然适用，例如在简单CRUD（创建、读取、更新和删除）应用程序中，可能不需要丰富的领域模型，或者在具有严格分层架构且远程通信较多的分布式系统中，它能够简化远程对象的传输。

总的来说，贫血模型可能适用于那些业务逻辑相对简单，或者领域逻辑不是系统重点的场景。然而，对于那些需要丰富领域逻辑、面向领域驱动设计的系统，则通常建议采用充血模型。

代码演示贫血模型

贫血模型是一种设计模式，其中业务逻辑主要位于服务类中，而不是领域模型中。可以通过一个简单的Java示例来演示贫血模型。在这个例子中，我们将创建一个Customer的实体类，它只包含数据，不包含任何行为。所有行为逻辑将被放置在一个单独的CustomerService类中。

Customer实体（贫血模型）

public class Customer {
    private String id;
    private String name;
    private String email;

    // 典型的 getter 和 setter 方法
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

在上面的Customer实体中，没有方法来表示业务操作。所有属性都是私有的，并且通过公开的getter和setter方法来访问。

CustomerService类（包含业务逻辑）

public class CustomerService {
    // 依赖注入存储库（比如数据库访问层）
    private CustomerRepository repository;

    public CustomerService(CustomerRepository repository) {
        this.repository = repository;
    }
    
    public void registerCustomer(Customer customer) {
        if (customer.getEmail() == null || customer.getName() == null) {
            throw new IllegalArgumentException("Missing data");
        }
        // 假设这里有电子邮件格式的验证逻辑
        if (!customer.getEmail().contains("@")) {
            throw new IllegalArgumentException("Email is not valid");
        }
        repository.save(customer);
    }

    public void changeCustomerEmail(String customerId, String newEmail) {
        Customer customer = repository.findById(customerId);
        if (customer == null) {
            throw new IllegalArgumentException("Customer not found");
        }
        // 假设这里有更多的业务逻辑来检查电子邮件

        customer.setEmail(newEmail);
        repository.save(customer);
    }

    // 可能还有更多关于客户的业务操作
}

在CustomerService类中，所有的业务逻辑都是通过方法来表示的，实体类Customer自身不包含任何业务规则或行为。

优点和缺点

优点：

简单直观：数据模型很容易理解，因为它们只是简单的数据容器。
分层清晰：在多层架构中，业务逻辑严格地和数据模型分离，服务层清晰地负责处理所有业务逻辑。

缺点：

低内聚：业务逻辑分散在多个服务中，而不是和数据一起封装在实体中。
可维护性差：随着时间的推移和业务逻辑的增长，服务类可能变得非常庞大和复杂。
面向过程的设计：这种模式更像是传统的面向过程设计，不符合面向对象编程的原则，如封装和对象身份。

在真实世界的复杂应用中，贫血模型可能导致难以管理和维护的代码库。为了避免这些问题，现代的应用程序开发通常倾向于使用更加丰富的领域模型，其中数据和行为在领域对象内部紧密结合。

充血模型

充血模型（Rich Domain Model），也称为充实模型，是一种软件设计模式，它强调将业务逻辑封装在领域实体内部，遵循面向对象编程（OOP）的原则。这种模型通常用于领域驱动设计（DDD）中，以创建更加有表现力的业务模型和可维护的系统。

在充血模型中，每个领域实体不仅包含它自己的数据（即属性或字段），还包含与之相关的行为（即方法）。这样，领域对象就可以自我管理其状态，并且能够实施和保证其业务规则的一致性。

充血模型的特点：

封装：数据和行为被封装在同一个领域对象中，这符合OOP的封装原则。
内聚：相关的数据和行为被放置在一起，增加了模型的内聚力。
自治：领域模型是自治的，它掌控自己的行为和状态，不依赖于其他对象。
表达力：领域模型通过其行为能够直接表达业务规则和意图。
复用性：封装好的行为可以在不同的上下文中被复用。

充血模型的实现示例：

以下是一个简单的Java示例，我们将创建一个Customer的领域实体类，并在其中封装业务逻辑。

public class Customer {
    private String id;
    private String name;
    private String email;

    // 构造函数
    public Customer(String id, String name, String email) {
        this.id = id;
        this.name = name;
        setEmail(email); // 使用下面的setEmail方法设置，以便进行验证
    }

    // Getter 方法
    public String getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public String getEmail() {
        return email;
    }

    // Setter 方法（包含业务规则）
    public void setEmail(String email) {
        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("Email is not valid");
        }
        this.email = email;
    }

    // 业务方法
    public void updateEmail(String newEmail) {
        setEmail(newEmail);
        // 还可以添加其他逻辑，比如发送邮箱变更通知
    }

    // 可能还有其他与客户相关的业务行为
}

在上述Customer类中，我们可以看到数据和行为紧密相连。setEmail方法不仅仅是一个简单的setter，它还封装了验证逻辑。而updateEmail方法则提供了一个特定的业务操作，包含更新电子邮件地址的业务规则。

充血模型的优点：

强内聚力：相关的业务逻辑和数据都封装在同一个领域对象中。
面向对象的设计：模型遵循OOP原则，易于理解和维护。
可维护性：业务规则和行为集中在领域对象中，方便追踪和修改。
高复用性：领域对象的行为可以在不同场景下重用，提高了代码的复用性。
易于测试：每个领域对象都可以独立测试，不需要依赖外部服务层。

充血模型的缺点：

概念密集：模型可能会变得复杂，尤其是在业务规则很多的情况下。
设计挑战：需要精心设计来平衡领域对象的职责，避免过度膨胀。

结论：

充血模型适合那些业务逻辑复杂，领域模型需要反映丰富业务行为的场景。它可以帮助开发者构建出高度内聚、易于维护和扩展的系统。通过这种方法，业务逻辑被组织得更为合理，代码更加清晰和可维护。然而，它也要求开发者有更深入的领域知识和面向对象设计的经验。

什么是TDD

测试驱动开发（Test-Driven Development，简称TDD）是一种软件开发方法，它强调在编写实际代码之前先编写自动化测试用例。TDD的目的是通过小步迭代来改善软件设计和提高代码质量。

TDD的工作流程：

TDD遵循一个简单的循环，通常被称为红-绿-重构（Red-Green-Refactor）循环：

编写一个失败的测试（红色）：
开始编写一个新功能前，先编写一个单元测试，描述期望的行为。此时运行测试，它应该失败，因为对应的功能尚未实现。
编写最简单的代码使测试通过（绿色）：
接下来，编写足够的代码以通过刚刚编写的测试。在这一步，不需要考虑代码质量，只需使测试绿色通过。
对代码进行重构（重构）：
现在测试已经通过了，接下来的步骤是重构刚刚写的代码，改善其结构和可读性，同时保持测试通过。这个阶段可以消除代码中的冗余，优化设计。
重复以上步骤：
对于新的功能或修复，重复上述循环，每次只针对一个小的功能增量。

TDD的关键原则：

测试先行：在编写任何功能代码之前先编写测试。
小步前进：以小的功能增量来开发软件，每次只解决一个问题。
快速反馈：测试提供了对系统行为的即时反馈。
持续重构：在整个开发过程中不断改善代码的设计和质量。
简单设计：只编写满足当前测试用例所需的代码，不做额外的假设。

TDD的优点：

提早发现错误：由于测试是首先编写的，因此可以在功能代码实现之前就发现潜在的错误和问题。
改善设计：TDD鼓励开发者思考如何设计代码以便于测试，通常会导致更好的软件设计。
促进代码重用：通过TDD，代码通常会更加模块化，易于复用。
提高代码覆盖率：由于一开始就编写测试，所以通常会得到较高的测试覆盖率。
减少回归错误：添加新功能或重构现有代码时，可以快速运行测试来确保没有破坏现有功能。

TDD的缺点：

学习曲线：对于新手来说，TDD可能有一定的学习曲线，因为它要求开发者调整他们的开发习惯和思维方式。
初始投入：TDD可能会在项目初期增加开发时间，因为编写测试需要额外的时间和努力。
维护测试代码：随着项目的发展，测试代码本身也需要维护和更新。

应用场景：

TDD尤其适合于那些对代码质量和系统可靠性有高要求的项目，如金融、医疗和航空航天领域的软件开发。同时，它也适合于追求敏捷开发和快速迭代的团队。

结论：

TDD是一种有效的软件开发实践，它通过测试来引导代码的编写和设计。当正确实施时，TDD可以显著提高代码质量，减少后期的缺陷，并使后续的维护工作更加容易。然而，它需要开发者具备编写有效测试的能力，以及对测试和代码设计的深入理解。

TDD代码演示

让我们通过一个简单的Java示例来了解TDD的实践过程。

假设我们要开发一个计算器应用程序，它可以进行基本的算术运算。我们将从实现加法功能开始。

第1步：编写一个失败的测试（红色）

我们首先编写一个测试用例，用来测试加法功能。

import static org.junit.Assert.*;
import org.junit.Test;

public class CalculatorTest {

    @Test
    public void testAddition() {
        Calculator calculator = new Calculator();
        assertEquals(5, calculator.add(2, 3));
    }
}

此时，我们还没有创建Calculator类和add方法，所以这个测试应该会失败。

第2步：编写最简单的代码使测试通过（绿色）

现在，我们编写足够的代码让测试通过。

public class Calculator {

    public int add(int number1, int number2) {
        return number1 + number2;
    }
}

运行测试，现在它应该通过了。

第3步：对代码进行重构（重构）

我们的add方法已经足够简单，可能不需要重构。但重构的目的不仅仅是简化代码，还可以改善代码结构或者提高代码可读性。在这个例子中，我们就假设不需要重构。

如果我们的add方法在实际情况中更复杂，或者我们在之后的开发中发现了更好的实现方式，我们可以在这个阶段进行重构。

第4步：重复以上步骤

现在我们添加一个测试用例，用来测试减法功能。

@Test
public void testSubtraction() {
    Calculator calculator = new Calculator();
    assertEquals(1, calculator.subtract(3, 2));
}

运行测试，它会失败，因为我们还没有实现subtract方法。

然后我们添加subtract方法。

public class Calculator {

    // ... 已有的 add 方法

    public int subtract(int number1, int number2) {
        return number1 - number2;
    }
}

再次运行测试，现在两个测试都应该通过了。

这就是TDD的基本流程。每次你想要添加一个新功能或改进现有功能时，你都应该通过写测试来开始。让测试失败，然后编写或修改代码来通过测试，最后重构代码以保持代码的质量。

在实际的软件开发中，你可能还会遇到需要对接口、异常处理、模拟外部依赖等复杂情况的测试，这些都可以使用TDD的原则来处理。重要的是，TDD不是一种测试方法，而是一种设计和开发软件的方法。它鼓励开发者从用户的需求出发，先思考如何验证功能的正确性，再实现功能本身。

DDD与TDD对比

领域驱动设计（Domain-Driven Design，简称DDD）与测试驱动开发（Test-Driven Development，简称TDD）是两种不同的软件开发方法，它们专注于不同的软件开发方面。然而，它们也可以相互补充，一起使用以提高软件质量和确保业务需求的准确实现。让我们深入对比一下这两种方法。