Is there any good practice for integrating functionality from independent libraries for later use?

Question

Software design

Good afternoon!

In reality, the essence of the problem is much simpler than the title of the question. For the same reason, I honestly looked for something similar to SO here, but I don’t even know how to formulate it correctly.

There is a conditional "internal corporate framework" for developing applications on it. And there are two completely separate entities in it: licensing (DRM, copy protection, that's all) and Windows services. Neither library is aware of the other, but both link to some common lower-level library. The end application can add either or both. It turns out something like plugins.

Situation: when updating a license through the user interface, you need to restart the service. And this is necessary for all applications where both licensing and services are used.

I absolutely do not want to make any of the libraries start to know about the other. It is clear that the easiest way to implement this scenario is in the final application, where they are both added. But it's very reluctant to do this every time in every application. I would like to prescribe such a dependence once and forget it.

I see the following ways to solve this problem:

1. All functionality lives in one thick library, and knows everything about everything. In fact, this approach is now being used, but I really want to separate all this from each other.

2. Three libraries are started: Licensing, Service and Licensing.Service. But this is a path to madness, since in fact such a library will have to be created for every possible combination of functionality used.

3. Interfaces are added to the conditional Core library that describe all the possible functionality implemented in individual libraries. The link is done somewhere at the same level through DI, for example.

4. On the contrary, a library is created that refers to all-all-all modules and orchestrates mutual dependencies between them.

5. Use something like a common data bus, on which commands like "LicenseChanged" will run, and the service module can react to them. In fact, everyone knows about everyone again, but the typing becomes string.

I have been reading Habr for a long time, but I don’t remember meeting any reflections on this matter. I would be grateful if someone can poke their nose into an article / book. Either I'm missing something obvious, or in a general way it is not solved. :) In general, the C# language, but I think that this is not important.

Answer 1

You can use a common bus, connect two entities there: Licensing and Service, and put an entity between them that knows about the LicenseChanged event and knows that the services need to be restarted during this event, as well as exactly how this can be done (refers to Service ). If you access the Service on the same bus, then in a situation where the Service is unavailable (not connected, for example), nothing will happen and will not happen - that is, you will not need to explicitly handle the case with the absence of the Service inside the binding entity.
The advantage of this solution is that the binding does not depend on the code of specific License and Service implementations. You may not do string typing if the bus can handle different types of messages one way or another - in extreme cases, you can at least come up with some kind of serialization for events. In addition, events still carry some information besides the name, so some kind of structure for these events will not hurt. But here I have already got carried away, because there were no such introductory ones. :)
I argue within the framework of the actor system, where it is easier for me to think about such scenarios, but it seems that in C # inside some other approach this is realizable. :)

Answer 2

Thank you for your reply! I didn't think anyone would see it. :)
To be honest, I have not yet come across tires in projects, so I may not understand something. The phrase "between them to put an entity that knows about the event LicenseChanged" confused me. And where to add this entity? Where will she live? In the final project, who will use these libraries? So it will have to be duplicated in each such project. Actually, my main question lies in the torment in this regard.
With typing, this point is also unclear to me. In order for the typing to be non-string, you need to describe the type of this event somewhere. It is logical to place it in the Licensing library, since this is its event. But in order for the entity that knows about it and restarts the service to understand this type, you need to add a link to this very Licensing library to it. Actually, again, the question is: where, where will this harness live?