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

Question

背景

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

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

通知

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

    public abstract void send();
}

短信通知

public class SMSNotification extends Notification {

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

电子邮件通知

public class EmailNotification extends Notification {

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

问题

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

Eric Evans 在他的《领域驱动设计》一书的第 107 页上专门介绍了 领域服务 的概念:

..., in most development systems, it is awkward to make a direct interface between a domain object and external resources. We can dress up such external services with a facade that takes inputs in terms of the model, ... but whatever intermediaries we may have, and even though they don't belong to us, those services are carrying out the domain responsibility...

• 如果相反，我使用 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 的新子类可以创建以扩展功能。 无论如何，对于不让实体与外部服务接口(interface)以及在 DDD 中根本不拥有实体的子类似乎达成了共识。
• 如果从 Notification 中删除发送通知的行为，那么放置它的地方必须知道通知的“类型”，并据此采取行动，我只能将其概念化为 if...else... 语句，这直接与 OCP 相矛盾。

Answer 1

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

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

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

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

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

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

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

除了domain包还有:

• 适配器 处理基础设施的包
• App 对象，其中所有接口(interface)都绑定(bind)到实现。
• [也可能有] config 包，但在我的例子中它很轻。

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