使用现有（第三方）数据模型（Java）进行域驱动开发

Question

首先，我想说我开发软件的标准方法可能是许多开发人员的典型方法......我的服务行为丰富，但没有状态，而且我的对象（Bean）只有状态和没有行为（我认为这通常被称为贫血领域模型）。

我决定在一个新项目中尝试域驱动设计（DDD）方法，但是我有几个问题真的让我感到困惑。

1. 我有一个现有的第三方数据库，我的组织使用（并且与业务紧密相关，我无能为力：我不希望任何评论提及这可能导致问题如果第三方改变了他们的数据模型......我知道!!）。我已经创建了hibernate实体来表示数据但是我不确定如何将其转换为符合DDD原则的内部模型表示（即封装数据访问的富域模型）。

2. 这类问题必须有模式，但我发现很难找到。这让我相信我可能以错误的方式做某事（即不是通常接近的方式）。

我目前的策略是：

• 确定hibernate实体中的关键实体，并尝试将它们与相关的Values对象一起打包（这真的很难，我相信因为我从数据开始并创建一个域...任何建议这种方法也很受欢迎）
• 对于我发现的每个包，我已经创建了一个用于管理实体的存储库
• 在每个存储库（例如StudentHibernateRepository）中，我抓住了我需要的hibernate实体并将它们包装在代理类中。
• 在每个代理类中，我添加了我的业务规则，这些规则通过使用包装的hibernate实体作为数据源（再次尝试使我的代码行为丰富）。

如果有人有类似经历的经验，请分享经验/模式。如果你能反思我采取的策略，也会有所帮助。

干杯，

JLove

Answer 1

富域模型是only part of DDD。将现有的，更糟糕​​但冻结的数据模型适应富域模型可能不值得。持久性无知是DDD的一个理想方面，但是在实践中，经常会做出妥协，并且不能简单地推迟诸如持久性之类的技术问题。

代理方法的一个问题是映射复杂性的增加。您的代理实体必须委托给底层的NHibernate映射对象，在某些情况下，这可能会变得很丑陋。

但是，如果没有域模型，您仍然可以获得DDD的许多好处。我首先尝试识别核心域和任何子域以及相应的有界上下文。然后，将所有用例封装在application services中，然后委托给您的NHibernate映射实体。您不会从行为丰富的实体中获益，但我发现在这些类型的场景中做出公平的权衡。