基于DDD实践,这个逻辑应该放在哪里,如何避免不必要的依赖?

时间:2009-06-15 16:23:51

标签: inversion-of-control domain-driven-design

我正在为我的网络应用添加一些逻辑来查找用户的地理坐标,存储它们,然后使用这些坐标查找时区并存储它。我首先要做的是将一个GeoCodeUser()方法添加到我定义为执行其他地图相关任务的MappingService。因为查找依赖于两个不同REST服务的两位数据,我将两个查找任务分解为AddressGeoCoder和TimeZoneCoder,并使用它们来检索数据和UserRepository来存储它们。这个解决方案的一个奇怪部分是虽然这个方法需要访问存储库和两个“编码器”,但是类中的其他方法却没有。所以每次我使用该服务做其他事情我都会得到依赖,我不需要然后放弃它们。所以这就是我想知道的:

  • 这应该在服务中(因为它协调不同的操作)还是可能在'用户'模型对象本身中?

  • 如果是这样,我应该根据它的依赖关系来定义服务吗?感兴趣的区域(即UserGeoCodingService),或者只是具有额外依赖关系的感兴趣区域(MappingService)?

非常感谢您的见解!

詹姆斯

1 个答案:

答案 0 :(得分:1)

恕我直言,DDD完全是关于模型,并表达领域专家如何说事情的工作。我对这个领域并不是很了解,所以我不能指出什么更有意义。您需要基于专家或一致的模型。如果您还没有型号,请立即停止编码,然后构建您的模型。

首先,您需要一种无处不在的语言来帮助您获得更好的洞察力,并相应地创建课程。基于感兴趣区域的分离是否对域专家更有意义?

领域专家如何解释这个过程?他们使用像AddressGeoCoder,TimeZoneCoder这样的术语吗?如果是这样,那么这是一个很好的设计。否则,你最好知道他们的想法。

关于这个只有一个使用存储库和两个编码器的方法的类,有一些可能的想法(参见或创建一个对域有意义的想法)。

  • 只有方法从参数
  • 接收其依赖项
  • 将此方法提取到其他类(如服务,如您所说)
  • 只在一个中总结这3个实体(如GeoCodeUserData,再次,如果这对域有意义的话)
  • 使用依赖注入框架来避免包括这些依赖项在内的额外工作
  • 让你的构造函数接受空值(并以域专家说应该完成的方式处理错误)
  • 您的其他想法,由域专家验证

DDD也是一项激烈的重构工作,一旦你对领域有了更好的了解,所以对东西进行测试是好事,所以你不必害怕做出必要的修改。