Again about access modifiers.

Good and clean architecture (especially from ‘Uncle Bob’) says that there should be inversion of control, and declaration should be separated from implementation. (It’s clear, so the declaration never knows about concrete implementation and should not be tightly coupled with it. Also, unit tests should not depend on the implementation with its own dependencies). Therefore, a good practice is to put declarations (e.g., interfaces) in one project and implementations in another.

But then we have to declare interfaces as public. However, these declarations can be low-level things (e.g., access to the database) that should not be exposed to other parts of the system. For instance, if we have a repository interface to access the database and declare it as public, there’s nothing stopping us in a web application from calling this repository directly from a controller (instead of via services), and only our internal rules can prevent this.

How do we solve this issue? And why does Visual Studio propose internal as the access modifier for classes by default? In practice, I often have to change it to public because in most cases interfaces are implemented in another project. However, making them public also allows them to be accessed from other projects, where they should be hidden by encapsulation rules.”