如果领域包括技术，技术可以成为领域模型的一部分吗？

Question

我有一个专门处理创建、编辑和生成包含业务相关数据的 Word 文档的域。我还有一个包含 OpenXML SDK (.net) 并为 WordDocument 提供高级 API 的库。

我的用例是用户可以创建这样一个 word 文档（通过相应的 WPF UI），向它提供一些自定义业务相关数据（例如插入图像和文本），然后最后保存更改并销毁实例。所以我需要跟踪 word 文档的内存实例来处理所有这些。

现在遵循 DDD 方式，通常我不希望任何技术泄漏到我的域模型中，但是我需要在我的文档聚合上具有行为（如 Open()、Save()、FeedData() 等）这当然需要应用于这样的单词实例。

如果不引用我的域中的那个库，这个 Document 实例应该驻留在哪里？我相应的应用程序服务是否应该处理这样的成员实例？但这似乎很奇怪，因为通常我的服务是无状态的，并且只会协调我的实体的行为。

我强烈希望将所需技术视为我的领域的一部分，在与我们的领域专家交谈时，我们实际上是在谈论“word 文档”，因此它是无处不在的语言的一部分。如果我的假设导致我走错路，我会有点困惑。

我想我的问题是，如果领域（及其语言）包含技术，技术是否可以成为领域模型的一部分？

Answer 1

如果领域包含技术，技术可以成为领域模型的一部分吗？

如果您不按照他们的预期行事，DDD 警察不会追捕您。

在 DDD 中，域模型（业务逻辑的表达）和应用程序（协调业务逻辑和我们在数字世界中工作所需的管道）之间存在重要的边界。

分离的动机：域逻辑是与应用程序逻辑分开的关注点——我们应该能够将域代码从一个应用程序“提升并转移”到另一个应用程序（从自定义桌面应用程序到网站，例如）;应用程序代码的更改原因与域代码不同。

此外，在领域逻辑中工作时，从上下文中删除所有应用程序关注点有助于编程过程 - 在我们的领域代码中，我们应该专注于“当客户放置一个订单”，而不会被诸如“我如何从数据库中获取他们的订单历史记录？”之类的应用程序问题分心

关于您的文档的一个重要问题 - 是 data on the outside 吗？还是data on the inside？

如果是外部数据 - 意味着您的域模型之外的某个人负责内容（例如：人类作者正在编写文档），那么您的域模型可能根本不关心文档。

如果是内部的数据——意味着你的领域模型负责文档的内容，那么你的模型就会知道一些关于它的事情。不一定要加载/保存——您的模型可能不太关心您使用的持久性解决方案，但肯定会更改文档模型本身。

您可能可以将电子邮件与电子邮件进行类比-域模型可能知道电子邮件的内容应该是什么，收件人的地址以及应该安排邮件的时间，但是域模型可能是 不包括 SMTP 客户端（通常是应用程序或基础架构问题）。