Простыми словами
Система превращается в «большой ком грязи», когда в ней нет устойчивых границ, а любое изменение цепляет множество случайных мест. Сначала быстрые обходные решения кажутся выгодными, но со временем понимание и доработка становятся всё дороже. Поэтому технический долг нужно не только учитывать, но и регулярно сокращать.
Пример при разработке
Все обработчики, SQL и UI-правила лежат в одном файле, потому что каждое срочное изменение добавлялось «рядом». Любая правка задевает неожиданные части.
Это редакционный пример применения, а не часть определения или доказательство концепции.Механизм действия
Сначала проверяют, есть ли исходное условие из определения. Затем смотрят, как оно влияет на структуру компонентов, потоки данных, ограничения и действия участников. Если эту связь не удаётся наблюдать, принцип не стоит использовать как готовое объяснение.
Пример в работе
В задаче «API» сразу применить привычное решение и назвать происходящее «Большой ком грязи», не проверив, действительно ли работает этот механизм. Так можно улучшить один симптом и пропустить основную причину.
Использовать «Большой ком грязи» как гипотезу: сначала определить границы ситуации и исходное состояние, затем менять только то, что связано с проверяемым механизмом, и смотреть на результат.
Ограничения
«Большой ком грязи» объясняет только часть происходящего в области «Архитектура ПО». Сам принцип не говорит, насколько сильным будет эффект в вашем случае, и не заменяет измерения. При другом масштабе, среде или временном горизонте результат может отличаться.
Источник
Brian Foote, Joseph Yoder. Big Ball of Mud. 1997.