Yii Framework

А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?

sda писал(а):А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?

в каком билдере?

zelenin писал(а):
sda писал(а):А в билдере в таком случае тоже отдельный метод делать, который будет вызывать отдельный метод сущности для восстановления из базы?
в каком билдере?

http://stackoverflow.com/a/40324/2868530

ElisDN писал(а): ↑2016.12.01, 19:52
sda писал(а):как сделать, чтобы domain events выбрасывались после сохранения агрегата?
Через $this->recordEvent(new Event(...)) в агрегате и $aggregate->releaseEvents() после сохранения.

а у Вернона читали решение? Там события выбрасываются сразу. Их ловит подписчик и отправляет в базу. Они консистентно сохраняются вместе с агрегатом, т.к. application сервис выполняет всё внутри транзакции. Потом кто-то читает базу и скидывает новые события в rabbitMQ. Без необходимости загрязнять агрегат $this->recordEvent/releaseEvents.

Классное решение, сам к нему пришел, потом уже прочитал. Юзаю для обработки картинок и гетерогенной репликации

В книге вот такая реализация на Java (опустил код методов).

Код: Выделить всё

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) {
		...
	}
}

Дальше он пишет, что все запросы выполняются в тредах и т.к. свойство subscribers является статическим, то оно будет делить область видимости между тредами. Чтобы этого не происходило он использует ThreadLocal. Это фича джавы позволяет под каждый тред создать отдельное статическое свойство.

В php такой проблемы нет, так как код выполняется не в тредах, а в отдельных процессах и выполняется синхронно. Но я пишу под node.js. Тут тоже код выполняется в отдельном процессе, но асинхронно. Пока один запрос ждет I/O, процесс начинает обрабатывать следующий. И соответственно возникает похожая проблема как с тредами в Java. Статическое свойство subscribers начинает делить область видимости между разными запросами и всё это решение ломается. Из коробки в node нет чего-то типа ThreadLocal из мира Java. Есть библиотека https://github.com/othiym23/node-contin ... al-storage с помощью которой насколько я понимаю можно решить эту проблему. Но она пролезет внутрь класса DomainEventPublisher, который является частью домена и в application сервисы где я буду подписываться на доменные события. Это всё не очень хорошо.

Не знаю что делать. Без статики это решение из книги вроде не сделать.

в go мы решаем эти проблемы мьютексами - гугл выдает либы для ноды.
https://www.google.ru/search?client=ubu ... tAH8opioBg

С мьютексами как-то сложно. Что если забить на то, что subscribers делит область видимости, но не добавлять нового подписчика, если такой уже есть. При первом вызове application сервиса, подписчик будет создан и добавлен, при следующих вызовах просто ничего не будет происходить т.к. такой подписчик уже есть. Теоретически должно получиться, что после первого вызова application сервиса единственный экземпляр всегда висит в памяти. Как думаете, какие будут проблемы ?

sda писал(а): ↑2017.05.18, 15:53 С мьютексами как-то сложно.

например? в го магически двумя строчками

sda писал(а): ↑2017.05.18, 15:53Что если забить на то, что subscribers делит область видимости, но не добавлять нового подписчика, если такой уже есть. При первом вызове application сервиса, подписчик будет создан и добавлен, при следующих вызовах просто ничего не будет происходить т.к. такой подписчик уже есть. Теоретически должно получиться, что после первого вызова application сервиса единственный экземпляр всегда висит в памяти. Как думаете, какие будут проблемы ?

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

Yii Framework

Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket

Re: Domain events и websocket