What is the way to reduce coupling between modules in NodeJS?

Question

JavaScript

Pre: There are several modules - a business entity (conditionally) in one module, connections and working with a database in the form of MongoDB and redis in another module, Winston with LogStash in the third one, and app.js itself in which all this disgrace is going. The code base is small (about 2000 lines, of which ~20% is NOT business logic). PS: for now :)
The goal is to make transparent logging and writing to the database of changes to the business entity and, in principle, remove connectivity to hell.
Problem: I don’t want to embed the code that works with the logger and the database into the business entity code
Possible solutions - I see either pub / sub in one form or another (MobX as an option), observer, mediator or MQ (lightweight if there are any for the node , haven't searched yet).
People, how do you act in such situations?

Answer 1

Problem: I don’t want to embed the code that works with the logger and the database into the business entity code

I don't see a problem here. Separate the work with the database and the logger into a separate module and connect it to your "business entity".
PS: MQ is useless here. I think you are creating a problem where there is none.

Answer 2

I wonder what others will answer, but I would just take a mediator, because this pattern is exactly what is needed in order to connect modules / facades with each other

Answer 3

In such small projects, I spit on connectivity and make the project go further.
Modularity is when it is necessary for one part of the system to work without the other.
Do you need a base? Can you work without a base? If you can't, then cutting is pointless.
Do you need a logger? Can you do without a logger? If you can't, then similarly - live with a logger.
If you unbind modules, then switch to DI, events and queues. Queues can be kept in memory, it is not at all necessary to raise the service separately.
It is possible, as Yustas Alexu said, to make a module that works as an adapter to the database from the outside, and inside - a mixture of a base adapter, a logger and other fakes.