При подключении модуля ему передается Экземпляр класса UnitOfWork и , соответственно, модуль может пользоваться всеми полями (репозиториями таблиц) и обращаться к их свойствам.
Это явное пренебрежение и нарушение Interface Segregation Principle. Не нужно так делать.
Репозиторий и UoW не противоречат друг другу. Даёте сервису репозиторий, а под капотом у него уже могут быть любые инструменты, в т.ч. UoW.
То есть, если модулю необходимо создать свою таблицу или использовать дополнительный функционал - то он не может это сделать, потому что в экземпляре UnitOfWork нет свойств и определенных методов.
Модуль меняет схему БД? Думаю стоит первоначально попробовать пересмотреть его логику работы.
Как правильно поступить, чтобы Ядро не подстраивалось под модули, а модули подстраивались под ядро. И именно модули использовали средства ядра для комфортной работы с базой.
В ядре лежит реализация работы с базой, или лишь объявления необходимых интерфейсов?
Для реализаций то есть отдельный Data Access Level.
По хорошему ваш слой с бизнес логикой должен объявлять нужные интерфесы для работы с хранилищем, а слой доступа к хранилищу эти интерфейсы реализовывать. В верхний слой нужная реализация попадает, соответственно, через какой-либо механизм инверсии зависимостей(DI)
Небольшое примечаниеОдин из слоев - "Data Access Layer", сокращенно DAL, который позволяет получить доступ к базе данных. Главная задача данного слоя - абстрагироваться от источника данных, так как мне нужно поддерживать и mysql и postgresql
Задача данного слоя - абстрагировать ядро от хранилища, а он уже может использовать любые фичи нужных БД как ему нужно.