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

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

我已经决定在一个新项目上尝试一种领域驱动设计（DDD）方法，但是我有几个问题真的很困扰我

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

这类问题肯定有规律，但我发现很难找到规律。这让我相信，我可能是在用错误的方式做某事（即，不是通常的处理方式）

我目前的策略是：

• 确定hibernate实体中的关键实体，并尝试将这些实体与相关的值对象打包在一起（我认为这非常困难，因为我从数据开始并创建一个域…任何关于实现这一点的方法的建议都是欢迎的）
• 对于我识别的每个包，我都创建了一个存储库来管理实体
• 在每个存储库（例如StudentHibernateRepository）中，我获取所需的hibernate实体，并将它们封装在代理类中
• 在每个代理类中，我添加了我的业务规则，通过这些规则将包装好的hibernate实体用作数据源（再次尝试丰富我的代码行为）

如果有人有做类似事情的经验，请分享经验/模式。如果你能反思一下我采取的策略，那也会很有帮助

干杯

JLove

一个丰富的领域模型非常有用。将现有的、更糟糕的、冻结的数据模型调整为富域模型可能不值得。持久性忽略是DDD的一个可取的方面，但是在实践中，经常会做出妥协，不能简单地推迟持久性等技术问题

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

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