architecture-feature-boundaries.md

---

title: Respect Feature Module Boundaries impact: CRITICAL impactDescription: Prevents tight coupling between modules tags: architecture, boundaries, nestjs, modules

Паспорт документа

• Статус документа: living standard
• Актуально на: 28 марта 2026 года
• Владелец: backend/platform-команда
• Пересмотр: при изменении инженерной практики, CI/CD, архитектурных правил или локального workflow
• Область применения: внутренние rule/reference-card документы для инженерной команды
• Связанные документы:
  • Индекс Agents
  • Команды разработки
  • Инженерные принципы

Respect Feature Module Boundaries

Impact: CRITICAL

NestJS modules must not reach into each other's internals. Cross-module communication happens only through exported services.

Incorrect (reaching into another module's internals):

// In seller.service.ts — directly importing catalog repository
import { CatalogRepository } from '../catalog/repositories/catalog.repository';

@Injectable()
export class SellerService {
  constructor(private catalogRepo: CatalogRepository) {} // Wrong!
}

Correct (using exported service from another module):

// In catalog.module.ts — explicitly export what other modules need
@Module({
  providers: [CatalogService, CatalogRepository],
  controllers: [CatalogController],
  exports: [CatalogService], // Only export the service
})
export class CatalogModule {}

// In seller.module.ts — import the module
@Module({
  imports: [CatalogModule],
  providers: [SellerService],
})
export class SellerModule {}

// In seller.service.ts — use the exported service
@Injectable()
export class SellerService {
  constructor(private catalogService: CatalogService) {} // Correct!
}

Rules:

• Modules only expose services, never repositories or internal DTOs
• Import modules, not individual providers from other modules
• If two modules need heavy cross-communication, consider merging them or extracting shared logic into a separate module