Opa, que solução bacana que você chegou nesse problema que eu também passei u... · leomeister

Opa, que solução bacana que você chegou nesse problema que eu também passei uns bons meses pensando sobre, até depois de muita pesquisa chegar em uma arquitetura parecida com a sua haha.

Mas uma pergunta pertinente, por qual razão você preferiu separar os components das features?

Por que em vez de:

├── components/       # UI Components (Client)
│   ├── auth/         # Formulários, etc
│   └── profile/      # Componentes de perfil
│
├── features/         # Business Logic (Server Actions)
│   ├── auth/         # login.ts, register.ts
│   └── users/        # get-all-users.ts

Você não usou:

├── features/
│   ├── auth/    
│   │   └── components/  # UI Components (Client)
│   │   └── actions/     # login.ts, register.ts
│   ├── users/
│   │   └── components/  # ...
│   │   └── actions/     # get-all-users.ts

Assim alocando todo o código relacionado a auth e user a um único lugar em vez de dois distintos?

Ótima dúvida! O modelo que você sugeriu é totalmente válido e funciona muito bem quando o foco é feature co-location. No meu caso, a escolha foi mais alinhada com DDD e separação de camadas: eu trato features/ como a camada de aplicação/domínio (use-cases, regras, fluxos) e components/ como camada de apresentação, que muda mais rápido e não deveria “contaminar” o domínio.

Em DDD, autenticação e usuários costumam ser capacidades transversais, usadas por vários contextos e interfaces. Separar UI da lógica facilita reaproveitar o domínio em outros cenários (admin, API, novos fluxos) sem arrastar decisões de UI junto, além de evitar que um “users” ou “auth” vire um mega-domínio acoplado à tela.