Когда жесткая связь важна или хорошая вещь?

Question

Из всех моих чтений и исследований по дизайну/шаблонам/принципам ОО я обнаружил, что общий консенсус заключается в том, что свободная связь (и высокая сплоченность) - это почти всегда лучший дизайн. Я полностью согласен с моим прошлым опытом работы с программным обеспечением.

Но предположим, что какая-то конкретная компания-разработчик программного обеспечения (в которой я не работаю) имеет какое-то сомнительно разработанное крупномасштабное программное обеспечение, которое взаимодействует с некоторым оборудованием. Модули (которые я никогда не работал) настолько плотно связаны, и вызовы функций, которые идут на 20+ уровней для управления состояниями. Границы классов никогда четко не определены, а случаи использования плохо придуманы. Хороший разработчик программного обеспечения (а не я) мог бы затронуть эти проблемы, но только отвергнутые более старшими разработчиками, что методы разработки (например, SOLID или TDD) на самом деле не применяются, поскольку программное обеспечение много лет работает с использованием «традиционной» методологии , и уже слишком поздно менять. И самые большие жалобы от клиентов (которые я не знаю, кто они) являются качеством продукта.

Из-за вышеизложенного нереалистичного сценария (я никогда не был исключением), я думал о том, есть ли случаи, когда жесткая связь предпочтительна или даже требуется? Когда есть случаи, когда разработчику необходимо пересекать границы модулей и разделять состояния, увеличивать зависимость и уменьшать возможности тестирования? Каковы некоторые из таких сложных систем, которые потребуют этого? Я не мог придумать хороший случай, поэтому я надеюсь, что некоторые из более опытных мастеров могут мне помочь.

Спасибо. Опять же, я не знаю эту компанию.

Answer 1

Плотно связанная архитектура объединяет приложения предприятия вокруг одной точки истины, которая часто является единой RDBMS с пространственной поддержкой. Типы связанных приложений включают в себя инженерный дизайн (CAD), управление записями объектов (ГИС), управление активами, рабочий процесс, ERP, CRM, управление отключением и другие корпоративные приложения.

Основным преимуществом тесно связанной архитектуры является то, что она обеспечивает быструю и эффективную обработку больших объемов данных, обеспечивает единую точку достоверности вместо нескольких, часто избыточных источников данных, и обеспечивает открытый доступ к данным во всем организация.

Плотно соединенные архитектуры полагаются на стандарты, такие как SQL, ODBC, JDBC и OLEDB, SQL/MM и простую спецификацию функций для SQL от OGC, чтобы обеспечить открытый и защищенный доступ к данным, включая геопространственные данные , по всей организации.

Взаимосвязанные веб-службы требуют значительных сокращений, в отличие от жесткой связи между клиентами и сервисом, что сводит к минимуму избыточность.

Одна из проблем с асинхронными слабосвязанными веб-службами заключается в том, что для некоторых бизнес-функций она может превышать емкость своего ресурса для серверов или системы очередей сообщений.

Взаимозаменяемые веб-сервисы могут быть переведены в режим жесткой связи, чтобы избежать перегрузки системы из-за нехватки ресурсов.