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

Question

根据Stack Overflow上的这个问题 ，在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上使用Javascript代码并在后端使用C＃代码，在这种情况下，您需要复制该通用基础架构代码（除非您想出一个更精细的解决方案来保持DRY） ）。