领域设计中的反应式编程

Question

我习惯于开发创建“域实体”的软件--这些实体“依赖”域中的其他实体。

假设我有这样的接口

package domain;

import domain.beans.City;

public interface CitiesRepository {  
  City get(String cityName);          
}

正如您所看到的，我返回的City也是一个域对象。这个CitiesRepository的实现可以在域外找到，并且可以依赖于数据库、http客户端、缓存的装饰器等。

我现在正在使用一个响应式框架-- vert.x --我正在尝试理解如何继续使用这样的模型。我不想要vert.x的具体答案，只想了解是否有任何模式/最佳实践来理解如何实现这一点。

在反应式编程中，几乎没有返回值，但总是有一些回调/处理程序在事件发生后使用它。我应该将我的接口重写为“反应式”吗？

package domain;

import domain.beans.City;

public interface CitiesRepository {  
  void get(String cityName, DomainHandler<City> cityHandler);
}

仅仅提供这个示例就让我有些头疼，因为在考虑实现时，我必须处理“反应式框架”的处理程序来“填充”我的域处理程序。

当使用反应式模型时，我应该停止思考这种设计吗？我应该选择一种可观察/承诺的方法吗？

如有任何提示，我们将不胜感激

Answer 1

在我参与的反应式系统中，有一个事件处理程序，它将使用存储库：

public void SomeEventHandler : IHandle<SomeEvent> {
public SomeEventHandler(CityRepository repo) {}
}

然后，您将在处理程序代码中使用现有存储库：

public void When(SomeEvent event) {
    var city = _cityRepository.Get(event.CityName);
// do something with city
}

在应用程序的CompositionRoot中，将注册处理程序以通过任何消息传递总线/反应流等接收/产生事件来处理事件。

所以我不想让存储库成为响应式的，而是添加一个事件处理程序来使用它。

Answer 2

对于反应式设计，您添加了一层间接的API调用方式，并在原始的普通规范之外指定了这一点。原因是，在异步设计中，你如何调用东西很重要，它并不总是一刀切的，所以最好不要做出早期的重大决定，或者将“它是什么/做什么”绑定到“它是如何做的”。

有三种常用的工具可以让事情变得异步：

通过的

• future/promise
• callback
• message

Future/promise在整个设计方面是三者中最具约束力的，在实现方面通常是最复杂的，你需要做很多动作来防止你的设计中的ABA错误和卡车期货，这些仍然在运行一些东西，但没有人需要结果。是的，它们抽象出并发性，是单数等等，但当你添加第一个时，它们就把你当作人质，而且它们很难摆脱。

回调在单个进程中是最快的，但是为了让它们在基于角色的系统中工作，或者跨线路工作，您不可避免地要使用消息。此外，当您需要第一个状态机时，您需要立即使用事件队列和消息。因此，为了更好地证明未来，最安全的方法是只使用消息。在消息和回调之间移动是非常简单的(如果可能的话)，因为这两种机制都很简单。

按键查找城市的协议可能如下所示：

protocol Requests
message GetCityRequest(name): Requests

protocol Responses
message GetCityResponse(cityMaybe): Responses

但是非常了解这个主题，我会说投资于泛型形式的“状态复制模式”，并将其用于简单的静态查找和动态订阅。把它弄对并不难，它将是你满足大多数系统需求的主要工具。