根据Stack Overflow上的这个问题，在DDD体系结构中，"helper"类可以根据其目的位于不同的层中。例如，以用户友好的方式格式化某些内容的帮助器将放在UI中。数据库助手将进入基础设施。
但是如果helper可以被多个层使用呢?例如年龄计算。在业务逻辑的模型层中可能需要Age。它被多个实体使用，所以它不应该在一个特定的实体中。还有一些地方仅仅为了UI中的显示目的而需要年龄。类似地，我有可以被多个层使用的字符串函数。例如，我的自定义Right和Left方法可以用于UI中的格式化，但它们也可以用于模型中，例如基于前缀的条件逻辑。
那么这些常用的方法应该去哪里呢?我的设置是这样的:
- UI
- <
- 应用程序/gh>
- 基础设施
Model是核心的，不依赖于基础设施，所以普通的帮助程序不能进入基础设施。我在考虑两种选择:
1)有另一层称为Common或similar，可以被任何层使用。这将在Model和Common之间创建一个依赖关系。
2)在任何需要的层复制helper逻辑。在UI中有一个年龄帮助器，在模型中有一个年龄帮助器。这将违反DRY，但不需要域依赖于"公共"层。
哪个选项更好?模型层依赖于"公共"层是可以的吗?
更新:
在这个问题被提出后的两年半里，我总结道:
- 像右、左这样的东西弥补了框架中的局限性，属于"公共"实用工具/助手组件，甚至模型/领域层也依赖于它。
- "Common" utilities/helper组件不应该很大。有了更多的经验，我发现许多我认为是助手的东西实际上属于领域模型。
- Age在域层中属于自己的类。就像地址、电话号码和钱一样，我认为这些东西是价值对象。理解值对象确实是我理解创建可重用的领域类的关键，这些领域类可以合并到其他类中。
我认为字符串帮助器略有不同-在这种情况下，您的自定义Right和Left方法实际上补偿了您的语言/平台的内置字符串类型中的限制-它与您的应用程序没有任何关系，因此在这种情况下，可以让它全局访问。
年龄计算示例更有趣，因为它封装了行为/逻辑，这是应用程序/领域的固有部分。在这种情况下，可能值得逐个评估是否值得在每个层中复制行为(违反DRY而支持SRP)。这是一个艰难的决定。虽然它们现在可能是相同的，但通过复制行为，你就给了这两种方法在未来彼此不同的机会。如果他们有不同的理由修改 ，这通常会发生。
根据我的经验，拥有一个包含所有帮助类/方法的CommonInfrastructure(或类似的)组件/层是正确的方法。您所描述的字符串帮助器和年龄帮助器都可以在那里(以及DateTime帮助器，字典，动态，Linq，等等)。
它应该是一个库，可以很容易地进行到下一个项目，因为它将是如此通用，没有任何依赖于当前的领域逻辑，并包含有用的代码为所有目的。
违反DRY的唯一原因是如果你需要Javascript代码在UI和c#代码在你的后端，在这种情况下，你需要复制公共基础架构代码(除非你想出一个更复杂的解决方案来保持它的DRY)。