Реактивное программирование в доменном дизайне

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); 
} 

Просто обеспечивая этот пример вызвал мне некоторые спагетти-головную боль, когда мышление в реализации, где мне приходится иметь дело с обработчиком «реактивной структуры», чтобы «заполнить» мой обработчик домена.

Должен ли я перестать думать об этом дизайне при работе с реактивной моделью? Должен ли я предпочитать подход Observable/Promise?

Любой намек будет очень ценен

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 приложения, обработчик будет зарегистрирован для обработки события через любой обмен сообщениями/реактивный поток и т. д. будет получать/производить событие.

Поэтому я бы не хотел, чтобы репозиторий был реактивным, скорее добавьте обработчик событий, чтобы использовать его.