Move from Monolith to Microservice Design

In our company we have reached a point where a monolith may not be the best solution. There is no need for improvement in performance, but due to the increasing modularity and customer-specific changes, the effort to operate the monolith is becoming more and more difficult.

The current situation:

The application runs centrally and provides and manages various data. Currently, all data are stored in a central database and are connected to each other by PKs and FKs. The data covers a broad spectrum such as material data, stock, orders and configuration.

Just as we imagine:

All individual parts should run independently of the other parts. That means orders, material, stock, configuration and logs are independent services that manage your data themselves. To keep the data up-to-date we wanted to use a message broker like RabbitMq. This should be done with C# and MSSQL.

So much for the initial situation and now for the questions 😊

• Let's say we want to display data from two different sources on one UI. Does this require a new service that combines the data and makes it available to the UI?
• What does it look like the other way around? For example, if the data is changed by the user, will the UI service simply forward it to the relevant service?
• Let's assume we have services A and B which in turn contain data A and B. A is dependent on B, i.e. A contains B. What do the interfaces look like in such a case? Does each service get an externally visible interface (REST/WCF), which makes it possible to manipulate data or only A and B can only manipulate date over the message bus?
• Is it common to have two interfaces, one external like WCF/Rest and one internal like RabbitMq?
• Is there a "design pattern", Book, Websit that says, for example, as long as condition A then do it like this and otherwise like this? (For the Microservice Design)
• Currently we use WCF for communication because only Windows clients are used and in my opinion it is quite easy to use. We would also like to stick to this for the external interfaces, but maybe there are alternatives that can do the same (including callbacks perhaps)?
• There is also the question of rights management. Is there a simple pattern with roles, groups, etc. that can be applied to a microservice architecture? Authorizing every method call sounds very costly.
• How is the data kept in the database? In case Service B needs data from Service A, will the data from A needed to run Service B be stored twice (at A and B) and changes will be transmitted from A to B via some kind of interface?
• And last but not least, how is the program structured? So let's say I have type A objects on service A and I consume the service with service B, I don't want to copy the classes to service B in order to use it. Does a common project which contains transfer objects make sense here or does this contradict the design?

I know that many questions depend strongly on the intended use and do not make sense in some environments, however I would like to ask you to share your experiences because there are many different opinions on this topic on the Internet. And by the way, we don't need any scalability, because the workload is more or less low.