@FerdinandBeyer After a few years of building, ( and reading clean architecture by Bob Martin ) I totally get decoupling architectural layers. I don't know I survived code bases before knowing this.

The strategy has already been very well explained in the literature. Clean arch, by Bob Martin.

Can't agree more! Someone tried to convince me that doing all development in Virtual Machines would be a good route to go. But unit tests ran 400% SLOWER in the VM,. making it so that we spent more time sitting there waiting to get feedback on code, rather than actually coding.

Enforce testing an the version control level. I never let my team submit code unless it passes all automated tests. Do not allow code to be submitted to any branch unless all tests pass, and the coverage is sufficient.

I used Vue. The front end code plugs into your domain. i.e: Vue knows about your domain, but your domain does not know about Vue. The front-end implements interfaces that your domain decides. I could switch the project over to React, NextJS or any other front-end framework because of the architechure. The source code cannot be shared because its for my work. But I can explain the method in more detail if you like.

"the Main is the dirtiest class." Bob does mention this, but your example does clarify it a lot. Thank you.

This does not really answer the question. The factory still needs to know the implementation and the BusinessRules would need to know the factory. So again the Dependancy rule would be violated.

I agree on this point. I tried making a a messaging system using NodeJS. Anything related to timing issues with the state on the server turned into hell. Weird bugs that were near impossible to trace.

Why do you want to decouple architectural layers? So that you can change one without effecting the other. Would you change an existing one or creating a new one? If you change an existing one, you are modifying existing code and breaking the open closed principle. So you have to create a new one. So you have a new implementation. (2 implementations for the same interface) So yes, the number of implementations is directly related to the reasoning for interfaces. If there is never going to be another implementation, then there is no reason for the abstraction. Avoid speculative design.

Just as a followup. I ended up coding a implementation of the Flux pattern, I found MVC too confusing because the data was moving bidirectionally. Flux combined with KnockoutJS seems to have simplified development a lot.

Flux is nothing more that the publish / subscribe pattern with a constraint that all data go through the dispatcher first. It guarantees the data does not go backwards (and cause confusion). Things like "Store", "Action" etc are just another way of saying Components of the system, and the Data that gets passed around.