DDD 架构 - 在哪里放置通用方法/助手 [英] DDD Architecture - Where To Put Common Methods/Helpers
问题描述
根据 Stack Overflow 上的这个问题, 在 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:
- 界面
- 申请
- 模型
- 基础设施
Model 是核心，不依赖基础设施，所以普通的 helper 不能进入基础设施.我正在考虑两种选择:
Model is core and has no dependencies on infrastructure, so the common helpers cannot go in infrastructure. I am considering two options:
1) 有另一个称为 Common 或类似的层，可以被任何层使用.这会在 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 中有一个 Age 助手并且在模型中有一个 Age 助手.这会违反 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.
哪个选项更好?Model 层可以依赖于一个公共"层吗?
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 等补偿框架中的限制的东西属于通用"实用程序/帮助程序组件，即使是模型/域层也依赖于该组件.
- 通用"实用程序/帮助程序组件不应太大.随着更多的经验，我发现许多我认为是助手的东西实际上都属于领域模型.
- 年龄在领域层中属于它自己的类.就像地址、电话号码和金钱一样，我将这些东西视为价值对象.理解值对象确实是我理解创建可合并到其他类中的可重用域类的关键.
推荐答案
我认为字符串助手略有不同 - 在这种情况下，您的自定义 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屋！
