Domain events и websocket
Re: Domain events и websocket
А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?
Re: Domain events и websocket
в каком билдере?sda писал(а):А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?
Re: Domain events и websocket
http://stackoverflow.com/a/40324/2868530zelenin писал(а):в каком билдере?sda писал(а):А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?
Re: Domain events и websocket
а у Вернона читали решение? Там события выбрасываются сразу. Их ловит подписчик и отправляет в базу. Они консистентно сохраняются вместе с агрегатом, т.к. application сервис выполняет всё внутри транзакции. Потом кто-то читает базу и скидывает новые события в rabbitMQ. Без необходимости загрязнять агрегат $this->recordEvent/releaseEvents.
Re: Domain events и websocket
Классное решение, сам к нему пришел, потом уже прочитал. Юзаю для обработки картинок и гетерогенной репликации
Re: Domain events и websocket
В книге вот такая реализация на Java (опустил код методов).
Дальше он пишет, что все запросы выполняются в тредах и т.к. свойство subscribers является статическим, то оно будет делить область видимости между тредами. Чтобы этого не происходило он использует ThreadLocal. Это фича джавы позволяет под каждый тред создать отдельное статическое свойство.
В php такой проблемы нет, так как код выполняется не в тредах, а в отдельных процессах и выполняется синхронно. Но я пишу под node.js. Тут тоже код выполняется в отдельном процессе, но асинхронно. Пока один запрос ждет I/O, процесс начинает обрабатывать следующий. И соответственно возникает похожая проблема как с тредами в Java. Статическое свойство subscribers начинает делить область видимости между разными запросами и всё это решение ломается. Из коробки в node нет чего-то типа ThreadLocal из мира Java. Есть библиотека https://github.com/othiym23/node-contin ... al-storage с помощью которой насколько я понимаю можно решить эту проблему. Но она пролезет внутрь класса DomainEventPublisher, который является частью домена и в application сервисы где я буду подписываться на доменные события. Это всё не очень хорошо.
Не знаю что делать. Без статики это решение из книги вроде не сделать.
Код: Выделить всё
public class DomainEventPublisher {
@SuppressWarnings("unchecked")
private static final ThreadLocal<List> subscribers = new ThreadLocal<List>();
private static final ThreadLocal<Boolean> publishing = new ThreadLocal<Boolean>() {
protected Boolean initialValue() {
return Boolean.FALSE;
}
};
public static DomainEventPublisher instance() {
return new DomainEventPublisher();
}
public DomainEventPublisher() {
super();
}
@SuppressWarnings("unchecked")
public <T> void publish(final T aDomainEvent) {
...
}
public DomainEventPublisher reset() {
...
}
@SuppressWarnings("unchecked")
public <T> void subscribe(DomainEventSubscriber<T> aSubscriber) {
...
}
}
В php такой проблемы нет, так как код выполняется не в тредах, а в отдельных процессах и выполняется синхронно. Но я пишу под node.js. Тут тоже код выполняется в отдельном процессе, но асинхронно. Пока один запрос ждет I/O, процесс начинает обрабатывать следующий. И соответственно возникает похожая проблема как с тредами в Java. Статическое свойство subscribers начинает делить область видимости между разными запросами и всё это решение ломается. Из коробки в node нет чего-то типа ThreadLocal из мира Java. Есть библиотека https://github.com/othiym23/node-contin ... al-storage с помощью которой насколько я понимаю можно решить эту проблему. Но она пролезет внутрь класса DomainEventPublisher, который является частью домена и в application сервисы где я буду подписываться на доменные события. Это всё не очень хорошо.
Не знаю что делать. Без статики это решение из книги вроде не сделать.
Re: Domain events и websocket
в go мы решаем эти проблемы мьютексами - гугл выдает либы для ноды.
https://www.google.ru/search?client=ubu ... tAH8opioBg
https://www.google.ru/search?client=ubu ... tAH8opioBg
Re: Domain events и websocket
С мьютексами как-то сложно. Что если забить на то, что subscribers делит область видимости, но не добавлять нового подписчика, если такой уже есть. При первом вызове application сервиса, подписчик будет создан и добавлен, при следующих вызовах просто ничего не будет происходить т.к. такой подписчик уже есть. Теоретически должно получиться, что после первого вызова application сервиса единственный экземпляр всегда висит в памяти. Как думаете, какие будут проблемы ?
Re: Domain events и websocket
например? в го магически двумя строчками
проблемы в том, что вы не хотите сразу научиться решать проблемы шаред доступа к памяти на примере одного кейса, хотя вас ждет такое еще не единожды - лучше заранее выбработать паттерн.sda писал(а): ↑2017.05.18, 15:53Что если забить на то, что subscribers делит область видимости, но не добавлять нового подписчика, если такой уже есть. При первом вызове application сервиса, подписчик будет создан и добавлен, при следующих вызовах просто ничего не будет происходить т.к. такой подписчик уже есть. Теоретически должно получиться, что после первого вызова application сервиса единственный экземпляр всегда висит в памяти. Как думаете, какие будут проблемы ?