DDD-在弹簧数据中维护单独的域类和实体类
我正在研究一个项目Spring Boot项目，其中有两个单独的软件包，名为域和persistence。
域软件包主要包含域类（基于业务需求设计），而permistence软件包包含通过扩展Spring Data提供的存储库来定义的存储库接口。
我已经使用了弹簧数据JPA域类中的注释，并且在定义存储库接口时也直接使用了这些类。一切都在这里运行良好。
但是我遇到的问题是，人们可以说，域类无需了解持久性实现，而域类别不需要在不使用Spring Data JPA注释的情况下保持清洁。这使我可能应该使用另一组类别的类（例如，具有或多或少属性的实体类）来实现持久性，以便我可以保持域类清洁。但是如果我这样做；
Spring Data存储库将与这些实体类一起使用，并且我将无法使用基于接口的存储库，因为我将始终必须映射<<<代码>实体对象由存储库返回到域类。- 我相信，在某个时候，我也会引入
dtos，当我达到此级别时，会有太多映射（Entity class/code>，然后<代码>域类 todtos）。我个人认为，从长远来看，此映射将是一个开销。
摘要 - 我是否应维护域模型类和entity类 ，还是应该只使用域模型类以及spring Data JPA注释和吻？
I'm working on a project Spring Boot project where there are two separate packages named domain and persistence.
The domain package primarily contains the Domain Classes (designed based on the business requirements) whereas the persistence package contains the repository interfaces defined by extending the repositories provided by Spring Data.
I have used Spring Data JPA annotations inside the domain classes and those classes are directly used when defining the repository interfaces as well. Everything works well here.
But the issues I have is that one could argue that domain classes do not need to know about the persistence implementation and domain classes should kept clean without polluting with Spring Data JPA annotation. This makes me this that I should maybe use a different set of classes (let's say Entity classes with more or less attributes) to implement the persistence so that I can keep the domain classes clean. But if I do this;
Spring Datarepositories are going to work with theseEntity Classesand I will not be able to use the interface based repositories out of the box since I will always have to map theEntity objectsreturned by repositories toDomain Classes.- I believe that at some point, I will introduce
DTOsas well and when I reach this level, there will be too many mappings (Entity ClassestoDomain Classesand thenDomain ClassestoDTOs). I personally think this mapping will be an overhead in the long run.
Summary -
Should I maintain Domain Model Classes and Entity Classes separately or should I just use Domain Model Classes along with Spring Data JPA annotations and KISS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为将存储库接口与域类区分开是错误的。存储库是域的一部分。他们的实施不是，但您没有处理实施，因为Spring Data（和JPA）提供了该实施。
如果您的域类和实体类应该是单独的，取决于它们是否有不同的需求。
您可能会遇到需要建模实体类以适应JPA的局限性或您使用的任何持久技术的局限性，并且您不想将其泄漏到您的域中。
但是，直到您遇到我认为不需要将它们分开。
如果您担心对实体的注释，则可能有助于意识到注释是极度弱的依赖性。即使在课堂路径上，您也可以使用您的实体。因此，从纯粹的角度来看，它们是一种气味，但实际上我仍然必须找到一个问题的情况。
如果您真的想摆脱它们，您可能想研究 jmolecules 然后将DDD概念转换为JPA注释或您想使用的任何内容。
I think it is a mistake to separate the repository interfaces from the domain classes. Repositories are a part of the domain. Their implementation isn't, but you are not dealing with the implementation since that is provided by Spring Data (and JPA).
If your domain classes and your entity classes should be separate things depends on if they have different needs.
You might encounter scenarios where you need to model entity classes to accommodate the limitations of JPA or whatever persistence technology you use and you don't want to leak that into you domain.
But until you encounter that I don't see the need to separate them.
If you are concerned about annotations on your entities, it might help to realise that annotations are an extremely weak dependency. You can use your entities without the annotations even on the class path. So from a purist point of view they are a smell, but in reality I still have to find a situation where they are problematic.
If you really want to get rid of them you might want to look into jMolecules, which offer technology agnostic annotations for DDD concepts that then get translated into JPA annotations or whatever you want to use.