When is tight coupling essential or a good thing?

Question

From all my readings and research on OO design/patterns/principles I've found that the general consensus is that loose coupling (and high cohesion) is the almost always the better design. I completely agree speaking from my past software project experiences.

But let's say some particular software company (which I don't work at) has some questionably designed large scale software that interacts with some hardware. The modules (that I never worked on) are so tightly coupled and function calls that goes 20+ levels deep to manage states. Class boundaries are never clearly defined and use cases poorly thought up. A good software developer (not me) would bring up these issues but only get turned down by the more senior developers that development practices (like SOLID or TDD) doesn't really apply because the software has worked for years using the "traditional" methodology, and it's too late to change. And the biggest complains from the customers (which I don't know who they are) are of the quality of the product.

Because of the above unrealistic scenario (I was never apart of), I thought about if there are cases where tight coupling is preferred or even required? When are there cases where developer needs to cross module boundaries and share states and increase dependency and reduce testability? What are some examples of systems that's so complex that would require this? I couldn't come up with a good case myself so I'm hoping some of the more experienced craftsmen can help me out.

Thanks. Again, I don't know this company.

Answer 1

A tightly coupled architecture integrates enterprise applications around a single point of truth, which is often a single spatially-enabled RDBMS. The types of applications that are linked include engineering design (CAD), facility records management (GIS), asset management, workflow, ERP, CRM, outage management, and other enterprise applications.

A major advantage of a tightly coupled architecture is that it enables the rapid and efficient processing of large volumes of data, provides a single point of truth instead of several, often redundant, data sources, and enables open access to data throughout the organization.

Tightly coupled architectures rely on standards such as SQL, ODBC, JDBC, and OLEDB, SQL/MM, and the Simple Feature Specification for SQL from the OGC, to provide open and secure access to data, including geo-spatial data, throughout the organization.

Loosely coupled Web services require substantial redundancies unlike tight coupling between clients and service, which minimizes redundancies.

One problem with asynchronous loosely coupled Web services is that for some business functions, it can exceed its resource capacity for the message queuing servers or system.

Loosely coupled Web services can be made to switch to tight coupling mode to avoid system overloads of scarce resources.