Я не понимаю при чем тут на одной машине или нет.

Кролик
база данных
редис
просто внутреняя пямять
что угодно

просто с памятью проблемнее востанваливаться после падения или ошибок.

Спасибо!

если в разных процессах то уже надо смотреть в сторону eventual consistency и всяких там компенсационных действиях

либо распределенные транзакции или блокировки (это обычно оч больно)

Казуальный вопрос.
Где должна располагаться конфигурация ? (ну к примеру конфигурация DI)
В инфре или апп?

имхо
di в app
остальная конфигурация в app и инфре (в app значения по умолчанию для разработки, а инфра должна иметь возможность повлиять на приложение и поменять значения по умолчанию на те что например в env пользователя или процесса, за это уже отвечает инфра)

Кхм.
Спасибо.
Мне нужно написать обертку над Di.
Я выношу это как отдельное ядро.
Подключаю к инфре
Конфигурирую инфру
После ифру подключаю к аппе

апп не должно зависеть от инфы
инфра должна зависеть от апп (направление стрелок другое)
инфра не должна у себя юзать классы из апп, инфра должна юзать либо свои классы либо свои зависимости, но никак не полагаться на апп.
имхо

хотя тут большой вопрос что считать app и инфрой

для меня инфра все что вокруг app (вспомогательные сервисы бд, балансировки и тд) и это окружение уже может влиять на апп и его настройки

Тогда DI не получится в app по вашему же ИМХО.

У меня есть 3 building blocks
Домен
Инфра
Апп

И сам проект вебапи

То есть 4 proj
Я соединяю апп и домены в инфре и инфру подключаю к проекту апи?

Подправил сообщение выше

Гляньте как схематично изображается Explicit Architecture. Помесь гексагональной и чистой. Там выделяют первичные и вторичные адаптеры. Где первичные - это запросы извне к вашей системе(контроллеры, консюмеры), а вторичные - это уже вы просите другие системы что-то выполнить(репозитории,email-шлюзы). И тогда имеет смысл выделить 4й слой UI. Где UI - первичные, а инфра тогда вторичные. Имхо кажется, что конфигурация приложения описывает связи между кусками системы и несколько перекликается с термином «инфраструктура», потому и конфиги в инфре имеют место быть

поидее из схемы станет понятно, что: смотря для чего выполнять DI и какие слои при этом буду затронуты. Инфра самый «грязный» слой, туда обычно всякую детальную шелуху кидают. Потому DI, Конфиги там смотрятся идеально

распологаться в инфре(то же что фреймворк, только добавляет детали для конкретного приложения) либо в фреймворке(модуль который оборачивает фреймворк затачивая его под твой стиль написания приложений), а вызываться в main в app

Так
Как я понял

у меня есть блоки общие для всех других блоков
Общий блок инфры -> там расположу обертку на DI и какие то общие вещи


Теперь модуль заказов
Блок инфры для этого модуля  это соединение апп, домен этого модуля + общий модуль инфры

После чего я инфру подключаю к вебапи

Если брать условный asp.net то в фреймворке будут всякие штуки вроде обертки над контроллерами и ActionResult<T> вызывающие через assambly(поиск по классам) классы валидации модели ModelValidator<T> и устанавливающие в контроллер фабрику запросов с фильтрами и CQRS если надо.
В инфре какой нибудь SMSController, конкретный метод доставки для того же CQRS и будет подсовываться DI.
В приложении будет инфрой вызван домен.

вроде норм

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