从我对OO设计/模式/原理的所有阅读和研究中我发现，普遍的共识是松耦合（和高内聚）几乎总是更好的设计。我完全赞同从过去的软件项目经验中说出来。
但是，让我们说一些特定的软件公司（我不在其中工作）有一些可疑设计的大型软件与某些硬件交互。这些模块（我从未参与过）是如此紧密耦合，功能调用深达20级以上来管理状态。类边界从未明确定义，用例很少被考虑。一个优秀的软件开发人员（不是我）会提出这些问题，但只有较高级的开发人员拒绝开发实践（如SOLID或TDD）并不真正适用，因为该软件已使用＆＃多年工作34;传统＆＃34;方法论，改变已经太晚了。客户最大的抱怨（我不知道他们是谁）是产品的质量。
由于上述不切实际的情况（我从来没有分开过），我想过是否存在首选紧耦合甚至是必需的情况？什么时候开发人员需要跨越模块边界并共享状态并增加依赖性并降低可测试性？系统的一些例子是如此复杂以至于需要这个？我自己无法想出一个好案例，所以我希望一些经验丰富的工匠可以帮助我。
感谢。再一次，我不认识这家公司。
答案 0 :(得分：0)
紧密耦合的体系结构围绕单一事实集成了企业应用程序，这通常是单个空间启用的RDBMS。链接的应用程序类型包括工程设计（CAD），设施记录管理（GIS），资产管理，工作流程，ERP，CRM，停机管理和其他企业应用程序。
紧密耦合架构的一个主要优点是，它能够快速有效地处理大量数据，提供单一事实，而不是几个通常是冗余的数据源，并且可以在整个过程中实现对数据的开放访问。组织。
紧密耦合的体系结构依赖于标准，如SQL，ODBC，JDBC和OLEDB，SQL / MM以及OGC的SQL简单特征规范，以提供对数据的开放和安全访问，包括地理空间数据，整个组织。
松散耦合的Web服务需要大量的冗余，这与客户端和服务之间的紧密耦合不同，从而最大限度地减少了冗余。
异步松散耦合Web服务的一个问题是，对于某些业务功能，它可能超过其消息队列服务器或系统的资源容量。
可以使松散耦合的Web服务切换到紧耦合模式，以避免稀缺资源的系统过载。