Forget the metaphor for a second. Technical debt isn’t just a design compromise or a lack of refactoring time. It’s a structural imbalance that arises when systems evolve without coherent patterns.
Причины дисбаланса по мнению автора:
- чрезмерное увлечение «лучшими практиками». Agile церемонии, TDD, микросервисы, CQRS, dependency injection etc. не заменяют архитектуру. Нельзя исправить ошибки декомпозиции: правильное определение границ между компонентами и взаимодействий, улучшая то, что находится внутри компонент
- иерархические вызовы вместо разработки bindable (связываемые, подключаемые) компонент
- … и отсутствие "модерации сообщений" (отдельный текст Дика The Magic of Message Moderation)
- шараханье от единственного монолита к хаосу случайных микросервисов вместо развертывания, называемого автором service nodes. Я бы назвал это осмысленным развертыванием
...
Ну а заканчивает автор замечанием, что это не фантазия или мечта, а реализуемая его командой реальность и что The architecture resists debt by design
Подытожу: идея переосмыслить источники технического долга мне точно нравится