Подумываю провести аналогии главы "40 основных приёмов по устранению технических противоречий" из книги Найти Идею с архитектурными рефакторингами в разработке ПО. Будет много сов, много глобусов. Стоит оно того, чтобы как минимум похихикать в процессе, а как максимум - поржать с того что все эти ваши рефакторинги придумали 40 лет назад. Заодно систематизирую кашу в голове.
25. Принцип самообслуживания.
Очень нравится концепция health-check, которые могут исправлять найденные проблемы, а не только говорить "мне херово". В ту же степь изначально спроектированные ограничения в сроке жизни данных - системы, которые не разрастаются, а агрегируют (при этом способны извлекать пользу из этих агрегатов), а затем и удаляют архивные данные и которые не надо обслуживать руками – офигенные.
26. Принцип копирования.
а. Вместо недоступного, сложного, дорогостоящего, неудобного или хрупкого объекта использовать его упрощенные и дешевые копии.
Буквально принцип CQRS, разделение читающей и пишущей нагрузки. Читать можно с множества дешёвых копий с небольшой приемлемой задержкой лага репликации, разгружая от читающей нагрузки мастер-реплику. Туда же вынос аналитики в отдельные BI системы, что даёт возможность не хранить архивы в рабочей базе.