0

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

我决定在一个新项目中尝试领域驱动设计 (DDD) 方法，但是我有几个问题确实让我很烦恼。

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

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

我目前的策略是：

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

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

干杯，

爱

4

1 回答 1

0

富域模型只是 DDD 的一部分。将现有且更糟糕但冻结的数据模型调整为丰富的域模型可能不值得。对持久性的无知是 DDD 的一个可取方面，但是在实践中，经常会做出妥协，并且不能简单地推迟诸如持久性之类的技术问题。

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

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

于 2013-04-16T15:35:14.193 回答