There are way too many layers of separation in this application. A single change takes hours because the change has to be performed in so many places. The application was built using a large number of layers so that they could be replaced with something else at a later time. The problem is that we never have time to replace anything because we spend all our time making simple maintenance changes.
Have you ever heard that story before? I hear it all the time. Applications are built using large enterprise frameworks with a many layers of abstraction so that nothing is tightly coupled. Well, sort of. The intention was to not tightly couple things. So different layers share common interfaces, but have separate classes implementing the same thing, simply because the object is in a different layer. But the classes are identical.
All the abstraction that was intended to make your life easier and more adroit when it comes to change has instead turned your application into a morass of quicksand so that very little can be accomplished. What is the solution? Do we simply throw well intentioned separation out the door? Do we reduce the amount of separation and merge different models?
Perhaps the answer is in ONION like architectures where duplication of classes may be reduced because the monolithic communication is replaced with a broader view of inter-process communication. Some think the answer lies in SOA and microarchitectures. That may be the case. But, even using microarchitectures there is a growing concern for consistency, or fragility. It is a different monster with expressing similar problems.
Where are we to go? Are there tried and true techniques we can follow? Are there emerging methods that show promise? What’s your position? Share your thoughts by leaving your comments here.
Cheers,
Ben