大佬教程收集整理的这篇文章主要介绍了解决 DDD 中的多态行为，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
有一种场景，其中 Credential 类包含数字 Proof。每种类型的 Credential 都可以支持多种不同类型的 Proof，例如 JWSProof 或派生自相同基类 (RSASignatureProof) 的简单 Proof 并指定不同的进行验证的行为。
假设客户端发送包含 JWS 证明的凭证，在收到数据后，控制器端点将其映射到 Credential（最终可能会在之后存储）并以某种方式识别其中包含的证明类型.它的任务是在处理（或保存它）之前对其进行验证，因此它应该使用相关类（在本例中为 JWSProof）中实现的逻辑，在收集进行验证所需的加密材料后使用工厂构造它.
所以我的问题是：您认为这是正确的方法吗？我觉得 JWSProof 有点无用，因为它的逻辑很容易变成静态函数。您将如何对这种情况进行建模以及需要多少存储库来存储所有这些类型的对象/类？
对于不需要更改的纯计算逻辑（我建议证明算法是这样的：它可能没有从验证到验证的状态），源代码（例如静态函数）是正确的存储库。
然后，您的 ProofRepository 基本上只是从证明的标识符（例如像 "JWSProof" 这样的字符串）到静态函数的映射（不同的语言会使建模更容易或更难，尤其是如果证明实现需要采用不同的参数）。
出于同样的原因，您可能拥有一个存储特定证明所需的加密材料的存储库。
,根据您的解释（请参阅问题的评论），每种类型的@H_874_42@证明在数据结构（在您的情况下只是一个字符串）方面对相同类型的输入数据进行操作，我们只关心具有不同的证明验证逻辑。
这听起来像@H_874_42@证明更像是行为（逻辑），并不代表域模型中的数据。这就是为什么我建议通过 strategy pattern 处理这个问题。这意味着每个不同类型的证明都有一个包含验证逻辑的策略实现。我不建议使用静态方法，因为这会使测试和维护变得困难。
您可以实现一个 Credential factory 来创建相应的 Credential 聚合，并且已经基于 @H_874_42@proof 类型注入了特定的 @H_874_42@proof 策略。
如果此解决方案适用于您的问题，您甚至不需要由于不同的证明逻辑而需要不同的 Credential 类类型。因为当@H_874_42@存储@H_874_42@凭据聚合时，它总是具有相同的结构并且只有证明类型的值（例如创建一个强类型的自定义 ProofType 值对象）不同。
以上是大佬教程为你收集整理的解决 DDD 中的多态行为全部内容，希望文章能够帮你解决解决 DDD 中的多态行为所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。