From Django Views to testable Python Use Cases.
Moved HR business rules out of Django Views/ViewSets into ORM-independent Use Cases that can be unit-tested without starting Django or a database.
The challenge
Business rules were embedded in Django Views/ViewSets and coupled to ORM operations. Testing this logic commonly required Django integration tests and a database; user lookup and permission checks were repeated across roughly 13 places.
My role
I extracted business scenarios into plain Python Use Cases, separated them from ORM-dependent request handling, and introduced a shared path for repeated user lookup and permission checks.
Engineering approach
Django continued to handle HTTP entry points while the business logic moved into independent Use Cases. The unit tests supplied mocked repositories instead of relying on Django initialization or real database access. One concrete refactoring target was user lookup and permission validation repeated across approximately 13 call sites.
The outcome
Business rules became independently unit-testable without Django or a database, and repeated access checks could be reused. The estimated count of dependencies between affected modules fell from about 321 to 201.
An automated analysis estimated ~321 → ~201 cross-module relationships among classes, functions and components in the same business scope, including the new Use Cases. These are approximate counts, not test totals or runtime gains; ~13 refers to the repeated user lookup and permission checks.