[chipdart]

> What works and makes sense to one group of people might not work or make sense to another group of people. I find that more literal-minded people are frustrated by what they see as unnecessary abstraction and are fine with duplicated code whereas people who think in abstractions have no problem seeing the bigger picture and are proponents of abstractions when the abstractions make sense to them.

I don't agree. I don't think this is an issue of having different points of view. It is an issue of being oblivious to constraints that result in this specific configuration.

If they do not understand the problem, they don't understand the solution either.

No one adds abstractions and interfaces because they like complexity. In layered architectures, interfaces and abstraction layers are used extensively to manage dependency relationships.

Take for example dependency inversion. Dependency inversion is used extensively to ensure that inner layers, the modules which should change less frequently, do not depend on implementation details implemented by outer layers. Your inner layers need to get data from other services, save data in a data store, etc. But you should not need to change your inner layers just because you need to call a service. Consequently, you eliminate these dependencies on external services by having your inner layers provide the necessary and sufficient interfaces they require to handle external data, and then have the external services implement these interfaces provided by internal services. This can be interpreted as an unnecessary layer of abstraction if you do not have a clue about what's happening. I mean, your inner layers could simply call a database, but instead they have an interface that's implemented God knows where, and then you need to hunt down how it's used. Except this abstraction layer is of critical importance.