Модульная архитектура и паттерн UnitOfWork в c#?

Это явное пренебрежение и нарушение Open-Close Principle. Не нужно так делать.

Не вижу нарушения, так как ядро не должно знать, какой сервис передавать модулю. Ядро не должно подстраиваться под модули.

Хорошо. Например я вынесу DAL из ядра и сделаю его отдельным слоем, на который остальные могут ссылаться.

Даёте сервису репозиторий, а под капотом у него уже могут быть любые инструменты, в т.ч. UoW.

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

Модуль меняет схему БД? Думаю стоит первоначально попробовать пересмотреть его логику работы.

Да, модуль должен иметь возможность менять структуру, как он пожелает. Например, модуль Рейтинга песни. Где он будет хранить данные о рейтинге? Или изначально создать в базе данных эту таблицу? А вдруг она вообще может не понадобиться, так как этот модуль будет не нужен.

Главное для меня - чтобы модуль имел свой DAL, который расширяет основной, дополняет его необходимыми только данному модулю свойствами.

Модульная архитектура и паттерн UnitOfWork в c#?

CreateTable это только вершина айсберга. Мне нужны и другие специфические методы.
Ну создал я таблицу. А к ней как обращаться? Проблема не в одном методе, а в том, чтобы модуль имел возможность делать все что он хочет и не быть ограниченным.