Module Structure in Magento MSI
Magento 2 is a highly modular system which provides possibilities for extension and customization on many levels. The modular design of the system composed of separate components (modules) that can be connected together. The beauty of modular architecture is that you suppose to replace or add any component (module) without affecting the rest of the system. Replaceability (interchangeability) was one of the main reasons behind introducing Service Layer in Magento 2, as utilizing Service Contracts and providing extension over them, 3rd party developers could enhance out of the box business logic or replace one without breaking the system and other extensions relying on these contracts.
In Magento 2 you will usually see the service contract of a module defined by a set of interfaces in the module’s /Api directory, so that Magento module brings both APIs and implementation for these APIs. A module interface expresses the elements (Entity interfaces and Services to manipulate them) that are provided and required by the module. The elements defined in the interface are detectable by other modules, and represent a gateway for communication with the module. The implementation contains the working business logic that corresponds to the elements declared in the interface.
But placing Service Contracts (API), Implementation and UI in the same module we combine different layers of the system in the scope of one component. So that there could be different scenarios and reasons for extension/customization which would affect different layers of the system, for example, to customize UI 3rd party dev would still need to customize the same module as if he would like to substitute implementation for out-of the-box business logic. Even if a developer needs to provide fully custom own UI - he/she would still end up having out-of-the-box UI in the module, it's just not possible not to have it in the codebase, even if developer no need it at all (i.e. usage Magento in a headless way).
Having a good modular architecture means to have loose coupling between components of the system, preserving an ability not to depend on the components which are not needed for particular deployment.