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

前端之家收集整理的这篇文章主要介绍了DDD架构 – 放置常用方法/助手的位置前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
根据Stack Overflow上的 this question,在DDD架构中,“帮助器”类可以根据其目的而在不同的层中.例如,以用户友好的方式格式化某些内容的助手将进入UI.数据库帮助程序将进入基础结构.

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

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

> UI
>申请
>模型
>基础设施

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

1)具有可以由任何层使用的另一个名为Common或类似的层.这将在Model和Common之间创建依赖关系.

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

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

更新:

在问这个问题后的2.5年里,我得出结论:

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

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

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

猜你在找的设计模式相关文章