Modular architecture and UnitOfWork pattern in c#?

Question

C++ / C#

Hello. Specially registered. Maybe I'll get an answer to my question here.
I am writing a program using modular architecture. That is, I have a "Kernel", and plug-ins use objects, events and other things that the kernel gives. The core is divided into layers. One of the layers is the "Data Access Layer", DAL for short, which allows access to the database. The main task of this layer is to abstract from the data source, since I need to support both mysql and postgresql. For data access, I decided to use the UnitOfWork pattern, since I need to control transactions. An example of this pattern can be found, for example, here https://metanit.com/sharp/mvc5/23.3.php
In this example, there are only 2 entities (tables). I have 15 tables and therefore my UnitOfWork has 15 properties.
Everything is great - I don't write repetitive code, I can easily change the database.
As I said earlier, I have a modular architecture. When a module is connected, an Instance of the UnitOfWork class is passed to it and, accordingly, the module can use all fields (table repositories) and access their properties.
Here is where I have a problem. That is, if the module needs to create its own table or use additional functionality, then it cannot do this, because the UnitOfWork instance does not have properties and certain methods. How to do it right so that the Kernel does not adapt to the modules, but the modules adapt to the kernel. And it was the modules that used the kernel tools for comfortable work with the database.
Injecting separate "Tables" into methods is not a good idea - up to 12 tables can be used in one module.
How to make it all extensible and independent? In the php world like Laravel, a lot of people just create model instances inside controllers - but that's like phew.
By the way, if I write under the desktop.

Answer 1

When a module is connected, an Instance of the UnitOfWork class is passed to it and, accordingly, the module can use all fields (table repositories) and access their properties.

This is a clear disregard and violation of the Interface Segregation Principle. You don't have to do that.
The repository and UoW do not contradict each other. You give the service a repository, and under the hood it can already have any tools, incl. wow.
Does the module change the database schema? I think it is worth initially trying to revise its logic of work.
Is the implementation of working with the base in the kernel, or just the declarations of the necessary interfaces?
For implementations, that is, a separate Data Access Level.
On a good note, your business logic layer should declare the necessary interfaces for working with the storage, and the storage access layer should implement these interfaces. The desired implementation gets to the top layer, respectively, through some kind of dependency inversion (DI) mechanism
Задача данного слоя - абстрагировать ядро от хранилища, а он уже может использовать любые фичи нужных БД как ему нужно.