问抽象域DDD

EN

关于您的方法的初步评论:小心!

开始建立一个特定的领域(例如航空公司的机票)是很有挑战性的。试图抽象出该模型的一部分以供以后的潜在重用(例如铁路票务、奥运会票务、酒店预订等)。伴随着三个重大风险：

• 沟通风险:您的模型将更难与业务专家共享。他们可能会和你的抽象概念混淆。这可能很快导致一种不被理解的感觉，紧张局势可能会出现。
• 准确性风险:商业专家自然会将抽象的票务实体映射到他们在日常生活中使用的具体概念。如果您不理解这种语义混淆的后果，您的抽象层可能很快就会变得非常具体。
• 项目风险:通过尝试一次交付两件事，即抽象引擎和具体适配器，您可能会遇到许多可能危及您的主要项目的其他问题。

什么时候做?

如果抽象仅用于一般实现，我的建议是使用另一种方法:首先负责您的初始票务系统并保持域模型干净，然后再重构。

然而，票务本身就是一个商业领域。有些做法跨越了原有行业的边界。例如，在欧洲，许多铁路公司采用了类似航空公司的票务原则(和系统)。动态定价、收益管理等一般问题。甚至是最近的创新，值得作为原始的商业概念来处理。

因此，如果您的抽象实际上是关于建模一个更通用的业务域，并具有其自身的buisness值，那么您的方法肯定是合理的。

如何用DDD ?

来实现

实际上，在大型和竞争性项目中，您所描述的情况是相当普遍的:几个领域可能必须进行交互。埃文斯在他的大蓝书中明确说明了这一点：

有界上下文:特定模型的限定适用性。边界上下文使团队成员清楚和共享地理解哪些内容必须一致，哪些内容可以独立发展。

有趣的是，在关于战略设计的部分，在第14章中，他给出了一个航运业务的例子，并将预订系统识别为一个独特的有限上下文。

有界上下文原理是指可能有几个域模型，每个模型都是在有界上下文中定义的。无处不在的语言适用于上下文。

为了保持概览和确保一致性，全局上下文地图应描述不同上下文的主要概念，并跨越边界绘制相关概念：

上下文地图:项目中涉及的有界上下文的表示，以及它们与它们的模型之间的实际关系。

如果上面链接到Fowler的文章还不够，我建议您在Evan的书中阅读更多关于这个主题的内容。如果你是专业的使用DDD的话，它绝对值得它的钱。

我目前正在尝试做的事情，我不确定它是否正确-是将项目模型与特定领域脱钩，并抽象地考虑它们。因此，它取代了航空公司的订票系统--成为一个更抽象的机票预订系统。

为什么？

您的域应该是您的业务规则所在。您的业务规则中没有一个是针对航空公司的预订系统的吗？如果不是的话，你为什么要让航空公司在系统中详细说明呢？

如果某些业务规则需要“航空公司”的概念，那么就属于该领域。我可以看到把抽象的订票系统功能拉到没有航空公司概念的库函数中。但那不代表你的地盘。它支持您的域。把票务库推到外层。

对于垂直枢轴，我也可以这样说。如果您希望从航空公司或预订系统中抽象出来，请编写一个垂直枢轴库并使用它。在你的领域里使用它。只是不要把它当作你的域名。

这似乎违反了直觉。你可能一直认为域名是最抽象的部分，所以票务系统变得更加抽象，要求它更集中。这不是域名。域推开了不专注于表达业务规则的内容。DB或GUI可能非常抽象。这不是让他们进入领域的理由。

域是指不了解系统细节但真正了解业务的人可以查看并看到用他们理解的语言表达的业务规则。