An architectural doctrine for NestJS projects: a breakdown of typical codebase degradation scenarios and the structural constraints that keep them from emerging as the feature set grows. A quick recap, to avoid going back to part 1. We left AuthService.signUp in a state that needs no defense: two hundred lines in one function, six parameters at the input, four independent business domains in one method, and five different repositories in one dependency. And we've already formulated which answer comes up first: split it across services — UsersService , ReferralsService , MarketingService , FraudService , PartnerService — each with its own zone of responsibility; leave AuthService as the orchestrator. This answer is the standard one, recognized by the NestJS community, and any team will adopt it for refactoring without extra discussion. Part 2 is about what happens when the team honestly carries this refactoring out.…