oop – 域驱动的设计概念

概述我正在使用域驱动设计构建的应用程序中的一些概念遇到一些麻烦. 我有以下几层： >申请 >域名 >基础设施 所以,我们假设我有以下类： >订单 > EmailService > OrderNotificationService > OrderApplicationService 显然,Order进入域层,OrderApplicationService进入应用层. EmailService是用于发送电 我正在使用域驱动设计构建的应用程序中的一些概念遇到一些麻烦.

我有以下几层：

>申请
>域名
>基础设施

所以,我们假设我有以下类：

>订单
> EmailService
> OrderNotificationService
> Orderapplicationservice

显然,Order进入域层,Orderapplicationservice进入应用层. EmailService是用于发送电子邮件的通用服务,并在基础结构层中实现. OrderNotificationService是用于发送订单通知的特定实现. OrderNotificationService使用EmailService发送实际的电子邮件.

所以,我的第一个问题是：OrderNotificationService是否可以实现为域服务,应用程序服务或基础结构服务？

对于我的下一个问题,让我们假设以下对象：

>员工
> SalesforceService

假设当员工加入系统时,他们也应该被添加到Salesforce. SalesforceService是一种使用Salesforce API注册用户的服务. SalesforceService是通过发送员工信息实现为应用服务将使用的域服务还是通用基础结构服务？

感谢您的建议.

解决方法 这听起来不像DDD

您的问题中没有太多关于您的域模型的讨论.您提到“员工被添加到系统和Salesforce”,但除此之外,从商业意义上讲,我并不真正了解您的应用程序的目的.我对“员工”和“Salesforce”的理解是基于对单词的熟悉程度,而不是基于对系统中模型的解释.

我真的不知道“订单应用服务”应该代表您的模型.我收到了“订单”和“订单通知”.似乎“客户”制作了“订单”,而某些“订购者”获得“通知”,但其中很多都是基于我之前对设计模式的了解.

您应该能够描述业务域模型,因为如果计算机不存在,它将起作用.如果你需要一个计算机术语来解释这个想法,它可能混合了模型中外在的东西.

显然,您需要将应用程序逻辑与您的域逻辑集成,但这不应该使您的问题混淆.但是,有办法解决这个问题.

你如何解决它

>您可以使用接口而不是特定于实现的类来为域层中的服务建模.这被称为interface segregation principle.有意义的是,您的模型的一部分包括在客户下订单时通知负责的员工.但是,没有必要将此通知的实施与其建模目的相结合.可能有主管在拥挤的办公室中通过对讲机发布通知,或者可能有自动系统发送的电子邮件.这两个示例都用于相同的业务目的.您可以拥有一个IOrderNotificationService接口,该接口只包含一个方法voID NotifyOrderReceived(Order order);而不是在您的域层中嵌入电子邮件服务.这样,您就可以在域层中获得所需的所有业务逻辑,而不会引入诸如“电子邮件”实现或数据库持久性等不必要的问题.我猜这个,但你的OrderNotificationService和Orderapplicationservice实际上是对同一事件的响应,但是一个具有数据库依赖性而另一个具有SMTP依赖性.两者都是基础设施问题

在许多情况下,针对单个接口进行编码就足够了.但是,存在一个问题,即您的域对象现在依赖于注入的服务或全局变量.此外,这可能表明这些实体对其依赖性了解太多.客户可能不需要知道订单如何处理的内部工作方式,而只需知道订单处理完毕并且他们将收到他们订购的订单.同样,员工可能不会将自己添加到Salesforce,因为他在成为员工之前不了解它.他所知道的只是他找到了一份工作.

这个问题有一个非常好的解决方案……

>您可以使用“域事件”模式.基本思想是域对象只知道刚刚发生了什么以及它们的状态如何被改变,但是不需要知道有关持久化或传播该改变状态的任何信息.他们处理内部逻辑,然后提出“域事件”.这更类似于客户下订单然后大喊“哟,我订购了这个产品！”或者雇员被雇用然后大喊大叫,“哟,我找到了工作！”.采用这种方法将大大简化您的域逻辑,并使您能够更清晰地分离关注点. Udi Dahan有一系列精彩的博客文章,他解释了利用域事件模式背后的逻辑,并提供了一个非常简单但非常有效的实现.以下是一些链接：

> How to create fully encapsulated Domain Models
> Domain Events – Take 2
> Domain Events – Salvation

现在,如果您是那种喜欢在完全理解之前复制并粘贴代码的开发人员,我建议您从这些帖子中的第三篇开始.他们记录了Udi Dahan对这种模式的思考和体验的演变.最完善的代码示例出现在第三篇文章中.理想情况下,您将按顺序阅读所有这三个,以便您可以遵循他的逻辑并实际了解如何从他的方法中受益以及为什么它准确地表示“域驱动设计”.

作为“领域事件模式”的理由,Eric Evans在2009年撰写他的开创性着作后对领域驱动设计所学知识的回顾表明,Domain Events在他的书中是一个被忽视的核心构建块.他的演讲摘要可在here获得,并且演示文稿的链接可在here获得.

可能有助于您成功应用此模式的其他一些资源包括Jimmy Bogard的文章Strengthening your Domain: Domain Events和Martin Fowler’s Domain Event article.Bogard从引用的链接中链接到其他有用的DDD博客文章.

一般来说,

如果您真的想尝试应用域驱动设计,那么通过真正了解您的建模内容以及为实现目的而实现的内容,您将会更加成功.简单地使用您不熟悉的术语并标记代码就没有任何隐含的价值. DDD可以提供非常有用的帮助,但是如果你没有花时间去理解为什么要做出区别和设计决策,你最终会得到很多不必要的抽象和一般的混淆.

总结

以上是内存溢出为你收集整理的oop – 域驱动的设计概念全部内容，希望文章能够帮你解决oop – 域驱动的设计概念所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。