DDD体系结构-放置通用方法/助手的位置 [英] DDD Architecture - Where To Put Common Methods/Helpers
问题描述
根据此问题在堆栈溢出中，在DDD体系结构中，帮助程序"类可以根据其用途位于不同的层中.例如，以用户友好的方式格式化某些内容的帮助程序将出现在UI中.数据库助手将进入基础架构.
According to this question on Stack Overflow, in DDD architecture "helper" classes can be in different layers depending on their purpose. For example a helper that formats something in a user friendly way would go in the UI. A database helper would go in infrastructure.
但是可以被多个层使用的助手呢?例如年龄计算.业务逻辑的模型层可能要求使用年龄.它由多个实体使用，因此不应在特定实体中使用.另外，在某些地方，仅出于UI的显示目的需要年龄.同样，我具有可被多个层使用的字符串函数.例如，我自定义的Right和Left方法可以用于UI中的格式设置，但也可以在模型中使用，例如基于前缀的条件逻辑.
But what about helpers that can be used by more than one layer? For example age calculation. Age might be required in the model layer for business logic. It is used by more than one entity, so it should not be in a specific entity. Also there are places where age is required merely for display purposes in the UI. Similarly, I have string functions that can be used by more than one layer. For example my custom Right and Left methods could be used for formatting in the UI, but they might also be used in the model, for example conditional logic based on a prefix.
那么这些通用方法应该去哪里呢?我的设置是这样的:
So where should these common methods go? My setup is like this:
- UI
- 应用程序
- 模型
- 基础设施
模型是核心，并且不依赖于基础结构，因此公共帮助者无法进入基础结构.我正在考虑两种选择:
Model is core and has no dependencies on infrastructure, so the common helpers cannot go in infrastructure. I am considering two options:
1)拥有另一个称为通用"或类似层的层，该层可以被任何层使用.这样会在Model和Common之间建立依赖关系.
1) Have another layer called Common or similar that can be used by any layer. This would create a dependency between Model and Common.
2)在所需的任何层中复制帮助程序逻辑.例如，在UI中有一个年龄助手，在模型中有一个年龄助手.这将违反DRY，但不要求域依赖于公共"层.
2) Duplicate the helper logic in whatever layer is needed. Eg Have an Age helper in UI AND have an Age helper in the Model. This would violate DRY, but would not require the domain to have a dependency on a "Common" layer.
哪个选项更好?可以使模型"层依赖于公共"层吗?
Which option is better? Is it OK for the Model layer to have a dependency on a "common" layer?
更新:
问了这个问题以来的2.5年中，我得出结论:
In the 2.5 years since this question was asked I have concluded:
- 诸如右"，左"之类的东西可以弥补框架中的局限性，它们属于通用"实用程序/帮助器组件，甚至模型/域层也依赖于此.
- 公用"实用程序/帮助程序组件不应很大.有了更多的经验，我发现我认为很多帮助者实际上都属于领域模型.
- 年龄在域层中属于其自己的类.很像地址，电话号码和钱之类的东西，我认为这些东西都是价值对象.了解值对象确实是我了解创建可重用的领域类的关键，该领域类可与其他类结合使用.
推荐答案
我认为字符串助手略有不同-在这种情况下，您自定义的Right和Left方法实际上是在补偿您内置字符串类型的限制语言/平台-它与您的应用程序无关，因此在这种情况下可以全局访问它.
The string helpers are slightly different I think - in that case your custom Right and Left methods are actually compensating for a limitation in the built-in string type of your language/platform - it doesn't have anything to do with your application as such so in this case it's fine to have it globally accessible.
年龄计算示例更加有趣，因为它封装了行为/逻辑，这在很大程度上是应用程序/域的内在部分.在这种情况下，可能值得逐案评估是否值得在每一层中复制行为(违反DRY而采用SRP).这是一个艰难的决定.尽管现在它们可能是相同的，但是通过复制行为，您使两种方法将来有机会彼此分离.如果他们有不同的更改理由，通常会发生这种情况.
The age calculation example is a little more interesting as it encapsulates behaviour/logic which is very much an intrinsic part of your application/domain. In that case it may be worth evaluating on a case-by-case basis whether it's worth duplicating the behaviour in each layer (violating DRY in favour of SRP). That's a tough decision to make. Although they may be identical now, by duplicating the behaviour you are giving the two methods the chance to diverge from each other in the future. This would typically happen if they had different reasons to change.
这篇关于DDD体系结构-放置通用方法/助手的位置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
