От Django Views к тестируемым Python Use Cases.
Вынес бизнес-правила из Django Views/ViewSets в независимые от ORM Use Cases, которые можно тестировать без запуска Django и базы данных.
Исходная задача
Бизнес-правила находились внутри Django Views/ViewSets и зависели от ORM. Для их проверки часто требовались интеграционные тесты с Django и БД; получение пользователя и проверка прав повторялись примерно в 13 местах.
Мой вклад
Я вынес бизнес-сценарии в отдельные Use Cases на Python, отделил их от привязанной к ORM обработки запросов и сделал общую логику получения пользователя и проверки доступа переиспользуемой.
Инженерный подход
Django остался HTTP-слоем, а бизнес-логика перешла в независимые Use Cases. В unit-тестах вместо запуска Django и реальной БД использовались подставные репозитории. Конкретный пример рефакторинга — получение пользователя и проверка прав, которые раньше повторялись примерно в 13 местах.
Результат
Бизнес-правила стало возможно тестировать изолированно, без Django и БД, а общие проверки доступа — переиспользовать. По приблизительной оценке, число зависимостей между затронутыми модулями сократилось с 321 до 201.
По приблизительной оценке автоматического анализа в одной бизнес-области, включая новые Use Cases, число связей классов, функций и компонентов между модулями сократилось с ~321 до ~201. Это не число тестов и не измеренное ускорение; ~13 относится к повторявшимся проверкам пользователя и прав.