А как бы вы построили архитектуру?

Всем привет! В ходе изучения различных архитектурных подходов при разработке iOS приложений, наткнулся на интересный подход, но не совсем понимаю как правильнее реализовать. Да, такой подход больше все же подходит для коммерческих приложений с дальнейшей поддержкой. Но это как раз то, что нужно для меня :) В общем, идея такая - разделить приложение на три слоя:

Presentation Layer - здесь хранятся наши контроллеры со своей самодостаточной бизнес-логикой(VIPER, MVP, MVVP и тд)

Coordinator layer - здесь хранятся координаторы приложения. Координатор на каждый модуль также самодостаточен. Имеет фабрику для модуля, в которой создается контроллер и через отдельный класс сборщика, делает инъекции зависимостей для модуля (module assembly).

Data layer - здесь хранятся самодостаточные Нетворк менеджеры, менеджеры coredata/realm и так далее. Собственно, те объекты, методы которых мы вызываем в каком-нибудь интеракторе.

Архитектура на данный момент презентейшн леера - Вайпер.

Хочу сразу заметить, что все Presentation Layer вообще ничего не знает о каком-то координаторе, а уж тем-более о data Layer и других частей presеentation Layer. Интерактор знает только о протоколе какого-либо менеджера из data Layer.

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

ApllicationCoordinator имеет фабрику координаторов, который принимает в себя Нетворк менеджер для определенного модуля, в координаторе модуля собирается сам presеentation модуль и ему снова проставляется зависимость на network Manager. И получается, что мы вот так по сто раз проставляем зависимость, пробрасывая через объекты простенький network Manager.

Мне писали что-то про di-container, но я не совсем понял как его можно реализовать. А как бы вы поступили в данной ситуации и как бы вы в таком архитектурном подходе проставляли зависимости? :)