DDD从其他服务获取数据的责任

Question

我有一个名为investor的集合；投资者是由各种实体(如股票、债券)、一些价值对象(地址)组成的。

我想做一个服务，返回投资者的一些投资者的ID (/get-投资者/id/:id)

投资者的股票数据存储在数据库1中；债券存储在数据库2中，地址存储在数据库3中。

从其他微服务中实际获取数据应该在哪里呢？

在域模型中？(似乎不对)

由一个服务(从不同的存储库获取数据)协调，然后由服务组成包含所有这些信息的域模型？

Answer 1

投资者的股票数据存储在数据库1中；债券存储在数据库2中，地址存储在数据库3中。

如果是这样的话(你可以用这种方式来解决问题，这当然是有道理的)，那么在埃里克·埃文斯( Evans )看来，投资者可能不是一个整体。

(跨多个数据库回滚事务通常不是一个好时机。)

I想提供一个服务，返回投资者的某些投资者ID (/get- Investor /id/:id)

您似乎是在描述合并了从多个数据库复制的信息的报表。在这种情况下，域模型并不是真正必要的，因为我们不想尝试更改数据的正式副本，因此我们不需要描述如何约束更改的规则。

根据所具有的活性需求，在收到页面请求时，可以合理地从应用层查询不同的数据库。或者，您可以在后台执行这些查询，将所需的信息复制到本地缓存(然后由应用层查询)。

当您试图更改某些信息的正式副本时，同样的想法可以工作，并且需要来自其他地方的引用数据来计算要进行的正确更改。这是理想的情况--当决定从其他地方需要哪些数据的逻辑被琐碎地确定时。

当您需要在域模型中工作以确定您需要哪些引用数据时，至少有两种候选方法。

到目前为止，最常见的方法是使用“域服务”，它充当查询实现前面的外观--使用其他参数将服务传递给模型，并在需要时调用服务。

很少，但可行的做法是在域模型和应用程序代码之间设计一个协议，这样域模型可以请求它所需要的信息，而应用程序代码可以运行查询并将该信息传递给域模型。它的优点是将一些(可能是隐式的)错误处理从域模型中提取出来，并将其与其他I/O关注点放在应用程序代码中。但是，它显然不像只在需要时调用查询那么“容易”。

(记住:机器不太关心你怎么做--任何正确的实现都行。)但是有些设计对于需要维护它们的人来说更容易，不同的人在不同的环境中有不同的优先级。)