如何优雅地避免使用 DDD 的域实体对基础设施服务的依赖？

Question

背景

假设我的任务是使用领域驱动设计 (DDD) 在通知发送领域构建一个系统。该系统的关键要求之一是它需要支持各种“类型”的通知，例如短信、电子邮件等。

在开发领域模型的几次迭代之后，我继续将Notification 基类作为一个实体，将子类SMSNotification、EmailNotification 等作为子类（每个也是一个实体） )。

Notification

public abstract class Notification extends Entity<UUID> {
    //...fields...

    public abstract void send();
}

SMSNotification

public class SMSNotification extends Notification {

    public void send(){
         //logic for sending the SMS notification using an infrastructure service.
    }
}

EmailNotification

public class EmailNotification extends Notification {

    public void send(){
        //logic for sending the email notification using an infrastructure service.
    }
}

问题

• 使用这种当前的设计方法，Notification 的每个子类都与基础设施服务进行交互，其中基础设施的任务是与某些外部系统进行交互。

在介绍domain services 的概念时，Eric Evans 在他的《领域驱动设计》一书的第 107 页上专门用了一点页面空间：

...，在大多数开发系统中，在域对象和外部资源之间建立直接接口是很尴尬的。我们可以用一个根据模型接受输入的外观来装扮这样的外部服务，......但是无论我们可能拥有什么中介，即使它们不属于我们，这些服务也正在履行域责任...... .

• 如果相反，我使用 Evans 的建议在我的域模型中获取 SendNotificationService，而不是在 Notification 的每个子类上使用 send 方法，我不确定如何避免需要了解 提供了什么类型的通知，以便可以采取适当的基础设施操作：

SendNotificationService（域服务）

public class SendNotificationService {
    public void send(Notification notification){
        //if notification is an SMS notification...
        //    utilize infrastructure services for SMS sending.
        //if notification is an email notification...
        //    utilize infrastructure services for email sending.
        //
        //(╯°□°）╯︵ ┻━┻)
    }
}

我在这里错过了什么？

• 面向对象的设计原则促使我倾向于首先提出模型，包括Notification、SMSNotification 和EmailNotification 类。在Notification 的每个子类上实现send 方法是有意义的，因为所有通知都需要发送（证明其​​在Notification 中的位置）并且Notification 的每个“类型”或子类将具有特殊的行为方式通知已发送（证明在Notification 中制作send 是合理的）。这种方法还遵循开放/封闭原则 (OCP)，因为 Notification 类将禁止修改，并且随着支持新的通知类型，可以创建 Notification 的新子类来扩展功能。 不管怎样，似乎在没有实体与外部服务接口以及在 DDD 中根本没有实体的子类方面达成了共识。
• 如果从Notification中删除发送通知的行为，那么它的放置位置必须知道通知的“类型”，并采取相应的行动，我只能将其概念化为if...else...语句链，它直接与 OCP 相矛盾。

Answer 1

TLDR：如果您需要针对您的域执行一些基础架构逻辑，并且您需要从域中对其进行一些输入 - 不要内置它，只需使用适当的数据/标记声明意图。然后，您稍后将在基础设施层处理此声明的意图。

除了传递机制之外，各种通知是否有任何不同？如果没有 - 使用带有附加字段（枚举，如果列表已知，或某种标记）的通知值对象（或实体，如果您的域模型需要）来存储传递方法名称就足够了。也许，每个通知实例可能有许多这样的方法。

然后你有一个业务逻辑 - 一个域服务 - 来触发通知。域服务应该只依赖于域词汇。例如 NotificationDeliveryMethodProvider。

在您的适配器层中，您可以实现各种交付方法提供程序以与基础架构进行交互。以及根据 DeliveryMethod 枚举（或标记）中的值获取提供者的工厂。

基本上，以任何方式“发送”自己的操纵不是聚合的责任。它的职责应该是维护其状态，以一致的方式执行状态转换并协调其封闭实体/值的状态。并触发有关其状态变化的事件。

在我的一个项目中，我在domain 包下使用了以下子包：

• provides - 提供给客户端的域服务接口
• cousumes - 上游依赖的接口
• businesslogic - 领域服务的实现
• values - 带有代码的值对象以强制执行其不变量
• ...

除了domain 包还有：

• adapters 处理基础设施的包
• App 对象，所有接口都绑定到实现。
• [也可能有]config 包，但在我的情况下它很轻。

这些domain、adapters、App和config可以部署为具有明确依赖结构的不同jar文件，如果您需要为其他人强制执行它。

Answer 2

我同意你的观点，Notification 的主要职责应该是它可以发送自己。这就是它存在的全部原因，所以它是一个很好的抽象。

public interface Notification {
    void send();
}

此接口的实现是您正在寻找的基础设施服务。它们不会（不应该）被其他“业务”或“核心”类直接引用。

注意Entity：我自己阅读蓝皮书的收获是，DDD不是关于使用实体、服务、聚合根和类似的东西。要点是无处不在的语言，上下文，如何工作域本身。 Eric Evans 本人表示，这种思维可以应用于不同的范式。它不必总是涉及相同的技术问题。

注意其他评论 (@VoiceOfUnreason) 中的“常规”设计：至少在面向对象中，“保持状态”不是真正的责任。责任只能直接来自通用语言，换句话说，来自业务。 “常规”（即程序）设计将数据和功能分开，而面向对象则恰恰相反。因此，请务必确定您的目标是哪种范式，然后选择解决方案可能会更容易。

Answer 3

在开发域模型的几次迭代之后，我继续将 Notification 基类作为一个实体，将 SMSNotification、EmailNotification 等子类作为子类

这可能是一个错误。

public abstract class Notification extends Entity<UUID> {
    public abstract void send();
}

几乎可以肯定。你可以让它工作，如果你扭曲得足够多，但你走错路了。

领域模型中实体的职责是管理状态。还要让实体对跨进程边界发送消息的副作用负责，这违反了关注点分离。所以应该有一个合作者。

正如您将注意到的，对于 Evans，协作采用域服务的形式，该域服务本身将与基础设施服务协作以产生所需的结果。

授予实体访问域服务的最直接方法是简单地将域服务作为参数传递。

public class SMSNotification extends Notification {
    public void send(SMSNotificationService sms) {
        //logic for sending the SMS notification using an infrastructure service.
    }

SMSNotification 支持与 SMSNoticationService 提供者的协作，我们对此进行了明确说明。

您在此处提供的界面看起来更像Command Pattern。如果你想让它工作，你通常会在 constructor

中连接特定的实现

public class SMSCommand extends NotificationCommand {
    private final SMSNotificationService sms;
    private final SMSNotification notification;

    public final send() {
        notification.send(sms);
    }
}

您可以使用泛型做一些事情（取决于您选择的语言），这些事情可以使这些不同服务之间的相似之处更加明显。例如

public abstract class Notification<SERVICE> extends Entity<UUID> {
    public abstract void send(SERVICE service);
}

public class SMSNotification extends Notification<SMSNotificationService> {
    public void send(SMSNotificationService service){
        //logic for sending the SMS notification using an infrastructure service.
    }
}

public class NotificationCommand<SERVICE> {
    private final SERVICE service;
    private final Notification<SERVICE> notification;

    public final send() {
        notification.send(service);
    }
}

这是主要的方法。

有时适合的替代方法是使用穷人的模式匹配。不是传入特定类型实体所需的特定服务，而是将它们全部传入....

public abstract class Notification extends Entity<UUID> {
    public abstract void send(SMSNotificationService sms, EmailNotificationService email, ....);
}

然后让每个实现精确地选择它需要的东西。我不认为这种模式在这里是一个好的选择，但它是一个偶尔有用的俱乐部。

您有时会看到的另一种方法是在构造实体时将所需的服务注入到实体中

SMSNotificationFactory {
    private final SMSNotificationService sms;

    SMSNotification create(...) {
        return new SMSNotification(sms, ...);
    }
}

再一次，一个很好的俱乐部在包里，但不适合这个用例 - 你可以做到，但突然间需要了解很多额外的组件来了解通知服务，以便将它们送到需要的地方成为。

notification.send(service) 和 service.send(notification) 之间的最佳选择

大概

notification.send(service)

使用“告诉，不要问”作为理由。您将协作者传递给域实体，它决定 (a) 是否协作，(b) 将什么状态传递给域服务，以及 (c) 如何处理返回的任何状态。

SMSNotification::send(SMSNotificationService service {
    State currentState = this.getCurrentState();
    {
        Message m = computeMessageFrom(currentState);
        service.sendMessage(m);
    }
}

在边界，应用程序不是object oriented；我怀疑当我们从域的核心向域移动时，我们会看到实体让位于值，让位于更原始的表示。

在阅读了一些关于纯域模型的内容之后，我不确定那里不应该有任何 IO

事实上，这有点混乱。域服务的动机之一是将域模型与 IO 分离——所有 IO 关注点都由域服务实现处理（或者更可能是由域服务与之协作的应用程序/基础架构服务）。就实体而言，所涉及的方法只是一个函数。

另一种方法是在关注点之间建立更多的分离；你让两个部分之间的编排变得明确

List<SMSRequest> messages = domainEntity.getMessages();
List<SMSResult> results = sms.send(messages)
domainEntity.onSMS(results)

在这种方法中，所有的 IO 都发生在 sms 服务本身内；与模型的交互被限制在内存表示中。您已经有效地获得了一个协议，可以管理模型中的更改和边界处的副作用。

我觉得 Evans 是在建议 service.send(notification) 作为接口。

我认为，对于课程而言，将实体传递给负责协调模型中多个更改的域服务是有意义的。在聚合更改的上下文中，我不会选择这种模式来与边界进行状态通信。