Monolithic Message-Oriented Application (MMOA)

>Сервисы получают и отправляют сообщения, и это единственный способ, которым они взаимодействуют друг с другом. В этом конечно есть значительный оверхед — вызвать метод с передачей сообщения будет по всякому быстрее, чем слать их через каналы и шину.

Я тоже как то копал в этом направлении, потом забросил. Может вернусь к своему проекту, доделаю, а пока просто выложу здесь пару мыслей, может кому пригодится.

Основная засада при реализации такой архитектуры — в размазанности кода. Исходя из имеющихся практик во первых программист стремится разбить все на модули, во вторых тупо ограничен форматом используемого языка.
На мой взгляд, сначала надо определится с абстракциями. Кусок кода, принимающий и отправляющий сообщения — это агент. Способ отправки — это транспорт. И не важно — через вызов метода или по шине, если мы указали связь, то в любой момент должны иметь возможность поменять транспорт и легко пересобрать приложение.

Далее — об ограничениях языка. При программировании мы как правило упираемся в то что программа разбита на какие то части, каждая хранится в отдельном файле. В нашем случае это рудимент, который мешает программить. Почему? Потому что именно стремление рассовать все по файлам и приладить древовидную структуру приводит нас к модулям и прочему. Оно неплохо само по себе но есть другой путь.
Давайте рассмотрим разработку программы с потоков (flow) — именно так, как ее обычно обсуждают с бизнесом. То есть у нас есть определенные диаграммы состояний и потоков, и вот эти диаграммы с точки зрения приложения, работающего на обмене сообщений — и есть исходный код программы.
То есть мы задаем агентов, задаем связи между ними, на каждую связь указываем формат сообщения (или он может браться из описания агента) и указываем тип транспорта (вызов метода, tcp, rabbit-agent, да все что угодно) — и компиляем.
И вот тут самый смак. То, что мы сейчас ковыряем и называем исходниками — должно быть результатом компиляции таких диаграмм. То есть это что то вроде DITA — набор кусков кода (описыващих агентов) и набор правил, которые собирают агентов в модули и прикручивают к ним транспорт.
Знаю что запутанно, попробую пояснить на конкретном примере.
Стандартный сервис — клиент — бекэенд — база
на клиенте пишем на js, на бэке пусть будет php и база скажем postgresql, весь интерфейс на хранимках, две схемы — паблик и бэк.
Рассмотрим стандартный запрос к апи
клиент делает какой ни будь fetch, php делает какой нибудь odbc->query() а sql отрабатывает какую либо хранимку.
В обычном проекте это будет лежать в трех локациях по десятку файлов. Как это могло бы быть?
В одном файле

process some_api_request tags api{
    agent client: javascript{
        fetch бла бла
    }
    agent back: php{
        odbc->query(); бла бла
    }
    agent db: plpgsql tags schema=public{
        create function бла бла
    }
}

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

build client.js as select all where agent=client; или что то в этом роде
build api.php as select all where process has tag api AND agent=back;
build db_public.sql as select all where agent=db and tag schema=public;

То есть на этапе проектировании мы имеем весь код процесса в одном месте. А после сборки мы растасовываем код по контекстам. DITA в чистом виде но для программирования. Один агент естественно может участвовать в разных процессах (можно описать его в одном месте а в описании процессов просто инклудить)
Из одного набора агентов разными правилами сборки можно собирать разные версии софта (для разных сред)
Поменять обмен сообщениями с tcp на rabbit можно просто указав другой транспортный агент.
подходящие под реализацию архитектуры — тот же веб, значительная часть сетевых прилад, расширения броузера (контент скрипты + бэк скрипт + попап — все обмениваются сообщениями + они могут обмениваться с сервером)
В общем есть куда применять )

Плюс к этому уже можно прикручивать gui и получить довольно серьезную и удобную среду разработки.
Один не потяну, потому и забил. Искал готовое — чет не нашел. Появятся интересующиеся — велкам.

gearbox, спасибо за интересный комментарий. Есть у Вас к нему какие-то схемы?