Interface 非域服务接口

在学习领域驱动设计的过程中，我一直在总结以下解决方案（请注意，这种排序是字典式的，而不是依赖性的表示）：

以下是每个项目的概要：

域。模型：域实体和值对象（例如，

顺序

）

域.接口：域服务接口和存储库接口（例如

IOrderService

，

iordersepository

）

域服务：域服务接口的具体实现（例如

OrderService

）

基础设施。数据：存储库接口的具体实现（例如，

OrderRepository

）

基础架构。依赖项解析：依赖项注入解析

问题 现在我想提供非域服务。例如，用于发送电子邮件的电子邮件网关。我为此创建了以下项目：

基础设施。组件：非域服务的具体实现

问题 我将把这些非域服务（例如，

IEmailGateway

）的接口放在哪里

它需要能被域服务项目访问（一个

OrderService

可能需要你发出通知），所以它会进入域接口吗？我会说不，因为发送电子邮件不是特定领域的活动

我会说不，因为发送电子邮件不是特定于域的 活动

当然可以，但是您可以通过使用更高的域抽象来逃避。域不关心电子邮件，但通知将是一个完美的域概念。事实上，它似乎已经是普遍存在的语言的一部分，因为你在问题中使用了这个术语。因此，一些类似于

INotifier

的东西取代了

IEmailGateway

备选办法可以是：

• 让总经理通过基础设施中定义的IEmailService接口发送电子邮件

• 让订单实体或域服务提出请求。基础结构层中的EmailService侦听并发送电子邮件

---

如果发送电子邮件不是您的有限上下文的概念，那么它意味着它是另一个上下文的一部分。因此，您应该应用一些有界上下文集成模式，例如域事件的反腐败层

---

无论你选择什么，我都会看到你的结构和解决方案中的另一个问题，这将消除问题中的问题。尝试根据使用普遍存在的语言而不是对象类型的有限上下文和模块来构造应用程序。因此，与界面、模型和服务相比，您应该拥有产品、客户机、装运等。

这太棒了。我意识到，我需要更多地将我的领域思维从基础设施问题转移到业务需求上来。