DDD架构 - 放置常用方法/助手的位置

Question

根据Stack Overflow上的this question，在DDD架构中，“helper”类可以根据其用途位于不同的层中。例如，以用户友好的方式格式化某些内容的助手将进入UI。数据库帮助程序将进入基础结构。

但是可以由多个图层使用的帮助器呢？例如年龄计算。业务逻辑的模型层可能需要年龄。它由多个实体使用，因此不应该在特定实体中。此外，还有一些地方需要年龄仅用于UI中的显示目的。同样，我有多个字符串函数，可以由多个图层使用。例如，我的自定义Right和Left方法可以用于UI中的格式化，但它们也可以在模型中使用，例如基于前缀的条件逻辑。

那么这些常用方法应该去哪里？我的设置是这样的：

• UI
• 应用
• 模型
• 基础设施

模型是核心，并且不依赖于基础架构，因此常见的帮助程序无法进入基础架构。我正在考虑两种选择：

1）有另一个名为Common或类似的层，可供任何层使用。这将在Model和Common之间创建依赖关系。

2）在任何需要的层中复制辅助逻辑。例如，在UI中有一个Age帮助器，并且在Model中有一个Age帮助器。这会违反DRY，但不会要求域依赖于“公共”层。

哪个选项更好？模型层是否可以依赖“公共”图层？

更新

在问这个问题后的2。5年里，我得出结论：

1. 补偿框架中的限制的Right，Left等内容属于“公共”实用程序/帮助程序组件，即使模型/域层依赖于它。
2. “Common”实用程序/帮助程序组件不应该很大。凭借更多的经验，我发现许多我认为是帮助者的东西实际上属于域模型。
3. Age属于域层中自己的类。就像地址，电话号码和金钱一样，我把这些东西视为价值对象。理解值对象确实是我理解创建可以包含在其他类中的可重用域类的关键。

Answer 1

我认为字符串帮助器略有不同 - 在这种情况下，您的自定义Right和Left方法实际上补偿了您的语言/平台的内置字符串类型的限制 - 它与您的没有任何关系因此，在这种情况下，可以全局访问它。

年龄计算示例更有趣，因为它封装了行为/逻辑，这非常是应用程序/域的固有部分。在这种情况下，可能值得根据具体情况评估是否值得重复每一层中的行为（违反DRY以支持SRP）。这是一个艰难的决定。虽然它们现在可能完全相同，但通过复制行为，您可以使这两种方法在未来相互分离。如果他们有不同的原因需要改变，通常会发生这种情况。

Answer 2

根据我的经验，拥有包含所有帮助程序类/方法的CommonInfrastructure（或某些此类）组件/层是正确的方法。 如你所描述的String助手和Age助手都可以进入（与DateTime助手，字典，动态，Linq等）。

它应该是一个可以轻松传递到下一个项目的库，因为它是如此通用且不依赖于当前域逻辑，并包含用于所有目的的有用代码。

违反DRY的唯一原因是，如果您需要在后端的UI和C＃代码上使用Javascript代码，在这种情况下，您需要复制该通用基础架构代码（除非您想出更详细的内容）保持干燥的解决方案。）