Seperate the View layers from the backend layers and use clear boundaries for the DTO without any sideffects.

So you got a kernel with the shared business logic that gets linked with the view layer. with that kernel you can put the data ontop of it. there are ofc certain design decision to consider. Like the session handling or the database.

but if all of them are 'online only' applications a simple rest/graphql-API should do the trick.

Problems is ofc upgrades/caching so you most likely will need to build different namespacing for the API even if you don't need it at the moment it makes sense to put a 'version' in your model.

Pseudo Code Decorator
Struct MetaModel<T> {
   version: i32,
   model: T,
   .....
}

as an example or you could do it with path identifiers.

/v1/getModel

it depends on how you want to build the architecture. The core idea is boundaries and a monotonic concept (meaning you cannot take things away but add things)

or you just don't care and force all of the users to stay up to date all the time ;D.