CEMbSeriyKПроблема в том, что получение из инета может быть с ошибкой и надо как- то из второй подсистемы сообщить первой о необходимости повтора запроса. И тут они становятся зависимыми друг от друга!Я бы сделал так (мы недавно делали похожую систему, правда я потом отошёл от дел, поэтому точность не гарантирую):
- 2 очереди, одна с командами, вторая с ответами (у нас даже очередь с командами разбирали несколько исполнителей).
- обе очереди - это отдельные подсистемы, с API, которые по вводимым данным формируют у себя объект в своём формате. Т.е. если это ошибка, ты можешь установить через отдельный метод код ошибки, если надо ещё сообщение - через отдельный метод сообщение. И так далее. Тоже самое с командной очередью: свой объект, своё API.
- оба API делаются по необходимому минимуму.
- ни принимающая, ни обрабатывающая системы друг о друге не знают. Они так же не знают формат объектов в очередях, у них просто есть несколько функций, через которые они могут устанавливать/читать информацию о событии/команде.

кейс:SeriyKполучение из инета может быть с ошибкой- вторая система создаёт в очереди сообщений объект сообщения, передаёт в него код и текст.
- первая разгребает очередь, получает информацию об ошибке
- первая создаёт объект в очереди команд на повторное выполнение запроса.

скорее всего, есть какой-нибудь паттерн про это, но я в их названиях плохо разбираюсь

Балин! Да не в средстве доставки ошибки дело! Уже третий раз на этом циклятся!
Беда в том, что эти две подсистемы должны ОДИНАКОВО понимать произошедшии ситуации, т.е. теряют взаимную независимость, потому что одна подсистема должна подстраиваться под другую.

PetroNotC SharpSeriyK,
Откуда неприязнь к зависимостям?
ИС моделирует реальный мир. А не вымышленный.

Тогда надо отказываться от универсального функционала. Ведь если он зависим от чего- то специфичного, то каждый раз эта специфика будет разной.

Basil A. Sidorov"Смешались в кучу кони, люди ..."
Не нужно ничего такого : исключения для того и придуманы, чтобы много не думать.
В нормальной ситуации, необходимая информация об ошибке содержится в типе исключения. В редких случаях можно "завернуть" в исключение "что-нибудь дополнительное".

А типы исключений из воздуха появятся? У меня сейчас именно такая зависимость и присутствует: в одном модуле объявлены типы исключения, а второй модуль их порождает.

Пока я прихожу к такому решению: разделить задачу на:
1) универсальный неизменяемый функционал
2) все остальное

В этом случае п.1 можно положить в свою библиотеку функций (где лежат универсальные функции типа комбинация нескольких массивов в один) и не боясь устанавливать зависимость от этого неизменяемого функционала где только нужно. Иначе надо бояться в том числе изменения функций языка и с ними тоже работать через интерфесы (чтобы защититься от их изменения :) )

В представленном выше конкретном случае подсистему с бесконечным циклом надо лишить громкого звания подсистемы (забрав у нее интерфейс) и положить в общедоступные объекты, в ней определить необходимые для взаимодействия исключения и спокойно ее с этими исключениями использовать где нужно.

PetroNotC SharpSeriyK,
Преобразовывай при передаче в "OLE совместимые типы".
Или ещё во что то.
Главное что тебе как прогеру будет неудобно.

Шестая страница обсуждения, а вы так и не поняли, что зависимость появляется из- за необходимости ДОГОВОРИТЬСЯ и ОДИНАКОВО понимать происходящие ситуации. Хоть в 10 слоев заворачивайся обертками- все равно в конечном итоге встанет вопрос как с языка событий одной подсистемы перевести на язык действий другой подсистемы.