Domain driven design 如何强制使用域服务？

在您关于域服务的在线文档（“”）中，您有一个名为“我们如何强制使用域服务？”

在这里，您暗示有很多外部文档围绕着向实体中注入一种“策略”服务的概念，作为实现这一点的一种方法，但是文章对该类的实现、注入的位置以及如何使用该类都有点模糊。我一直在互联网上搜寻这种设计的例子，以强制使用域服务，但没有找到任何东西

只是浏览文档就留下了太多的问题

此外，我希望我能找到一个简单的Abp实现，它提供了一个例子，但找不到任何东西

我对此非常好奇，因为我发现这是过去大型项目的一个大问题：开发人员在应用程序服务层编写自己的代码，而不知道某些域驱动的“管理器”服务已经提供了这些功能

你能提供一个完全实现这个概念的小样本吗？使用Abp会很好，但是一个通用的例子也可以

保重,

杰森

一些想法：

• 该代码中的策略模式在强制使用域服务方面不起作用。这只会使任务分配更加模块化，更加符合SRP

• 防御性编程只能为你做这么多。当然，保护

  AssignedPersonId

  使其不能直接分配是一件好事，但程序员也可以将其改回public。不要过分依赖技术代码来防止糟糕的开发人员行为——共享实践和团队文化更有效

• 质疑应用程序示例或模板代码（正如您所做的）是合理的。不要把那个准则当作福音真理——它本来就不应该成为模范。尝试你自己的东西，从错误中学习。经验不是可以通过这样的文件传递的东西

---

您可以将

AssignToPerson

设置为内部

以便只能由域服务调用它。您可以始终使用方法注入，即
order.CalculateTax（taxServiceProvider）
其中
ITaxServiceProvider
可能有一个名为
GetTaxCalculatorFor的方法（Country Country、State State、TaxCode TaxCode）
或类似的内容。因此，为了计算税款，您必须apss一个TaxProvider实例，该实例解析特定于国家/地区的税务计算服务。由于它都封装在聚合根目录中，因此必须将服务传递给该方法（您必须通过封装确保不能从聚合外部设置税值）也请参阅一个更具体的例子。谢谢TSN。我越是考虑它，就越不想让实体知道外部服务。我愿意做一些简单而通用的事情，像一个允许设置属性的策略，但从根本上讲，我不喜欢把依赖注入到我的实体中。目前正在权衡只使用“内部”的利弊。是的，你的聚合（不是实体！！！）将具有这些外部依赖项，但这是真正封装特定逻辑的唯一方法。否则，您无法向订单添加一个位置，并确保其保持一致状态。如果在上述情况下，您将计算外部化，则可能出现不一致状态（即，通过向计算方法传递错误的参数）。我同意并欣赏这种反应。我喜欢传递“策略”的想法我认为这是一个很好的技巧，如果这是一种我从未偶然发现的设计原则，我想读更多关于它的内容，或者看到它的实现。我在任何地方都找不到我为什么要问的东西。考虑到这一点，我想这项政策更像是一个问题-虽然“策略”可能更适合那个特定的域。实际上在Abp项目中，它们在实体对象本身的同一程序集中实现它们的域类，所以在属性上使用内部似乎是最简单的解决方案。我不知道为什么昨晚我没有想到：-）好奇有没有什么意见？和往常一样，我在那场辩论中看到了相互矛盾的意见。