在DDD中的域层中导入外部库
我正在构建一个基于 DDD 和六边形架构的应用程序。 六边形架构建议您不应该用其他地方的逻辑污染您的域，您的域层应该是“纯粹的”并且仅包含您的业务逻辑。
但是，如果我有一个值对象，我想从外部库生成 ID，该怎么办？例如 UUID。
这并没有污染我的域，但我仍然在我的域层中导入第三方，并且它应该放置在基础设施层中。
但是，每次我想对时间格式、转换器执行此类操作时都执行此操作...它可能会变得有点乏味。
域层中的第三方导入是否有例外？如果是的话，取决于什么？
你们觉得呢？
非常感谢
I'm building an application based on DDD and Hexagonal Architecture.
Hexagonal architecture suggests that you shouldn't, let's say, pollute your domain with logic of elsewhere, your Domain layer should be "pure" and only containing your business logic.
But what if I have a valueobject where I want to generate an ID from an external library? UUID for example.
This is not contaminating my domain, but still, I'm importing a third party in my Domain layer and it's supposed to be placed in the Infrastructure layer.
However, do this every time I want to do this kind of things for time formats, converters... it can become kinda tedious.
Are there exceptions on third party imports in the Domain layer? If so, on what depends?
What you guys think?
Many thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DDD 指出，业务问题属于领域层，不属于业务问题的则不属于领域层。如果 ID 生成是业务逻辑，那么在域层中导入该库就没有问题。它实际上是域层的一部分，尽管您自己并不维护该部分。
当我们说领域层应该保持“纯粹”时，这意味着您的业务逻辑不应该受到基础设施或表示问题的污染。如果 ID 生成仅用于持久性问题（代理键），那么这就是基础设施问题，并且该生成应由持久性存储或基础设施适配器完成。
DDD states that what is business matter goes in the domain layer, what is not does not. If the ID generation is a business logic, then there is no problem in importing that library in your domain layer. It is actually part of your domain layer, although you are not maintaining that part yourself.
When we say the domain layer should remain "pure", it means that your business logic should not be contaminated with infrastructure or presentation concerns. If the ID generation is only for persistence concerns (surrogate key), then this is an infrastructure concern, and this generation should either be done by the persistence store, or the infrastructure adapter.