The mediator pattern implementation

[comeuplater]

Сделал две реализации:

Подобно проекту https://github.com/mehdihadeli/Go-MediatR/. В нем мне не понравилось, что там публикация событий которые не возвращают ошибок выделяется в набор отдельных методов NotificationHandlers и так же есть такой же набор для обработчиков которые возвращают результат в сигнатуре и два разных метода на отправку событий. Как по мне переусложнили решение. Но такое решение благодаря джереникам позволяет отлавливать ошибки на этапе компиляции, но ему присущи все +/- глобального доступа. К тому же сейчас глобальная версия использует локи, это вызовет замедление при нагрузке, но там можно будте заменить на подобное https://github.com/orcaman/concurrent-map

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

var m = NewRefUntypedMediator()

func strictSend[E any](m RefUntypedMediator, ctx context.Context,  event E) error  {
	return m.Send(ctx, event)
}

[comeuplater]

.Lock()

[emacsway]

В принципе, unsubscribe можно сделать вообще приватным, и удалять по индексу в массиве, а сам индекс хранить в локальной области видимости объекта Disposable

[comeuplater]

По сути да, но думаю публичность его лишней не будет

[emacsway]

нет объекта Сессии

[comeuplater]

Которая в application слое?

type Session interface {
Atomic(SessionCallback) error
}

[emacsway]

да, у нас же синхронная обработка доменных событий. Им нужно работать в той же транзакции.

[emacsway]

А лучше принимать интерфейс контекста. У нас по этой же причине объект сессии реализует интерфейс контекста.

[comeuplater]

Ага, это больше говей подход. Добавлю первым аргументом

[emacsway]

Почему не сделать здесь обычный вызов?

[comeuplater]

Потому, что используется reflect.ValueOf(handler) чтобы была возможность регистрировать несколько одинаковых обработчиков и при этом корректно их идентифицировать

[emacsway]

Кстати, тут может вернуться результат с ошибкой. Я смотрю, что Саша это предусматривал https://github.com/adzeitor/mediatr/blob/master/mediator.go#L124

[comeuplater]

Я думал про это, но знать о хендлерах характерно для Observer. Pub/Sub не должен знать о своих подписчиках, значит и ошибку обработки ему неоткуда вернуть. Да и если ошибка вернётся, как понять откуда она вернется и правильно ли ее обрабатывать в этом месте?

Рассматривая Mediator как частный случай Pub/Sub, решил, что ошибки стоит вернуть только на этапе подписки, а при отправке событий/команд они не нужны.

Но если нужны то можно добавить

[emacsway]

Я думал про это, но знать о хендлерах характерно для Observer. Pub/Sub не должен знать о своих подписчиках, значит и ошибку обработки ему неоткуда вернуть.

Не совсем понял. И Observer, и Pub/Sub, и Mediator - это паттерны инвертирования осведомленности. Они ничего не должны знать о своих подписчиках.

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

[emacsway]

А тут multierror может вернуться...

[emacsway]

Команда может вернуть результат.