Os pacotes devem refletir quem pode mudar
Uma organização possível é domain, application, adapter.in.web e adapter.out.persistence. O domínio contém regras e tipos. A aplicação expõe casos de uso. Adaptadores traduzem HTTP ou SQL para esses contratos. O módulo externo pode importar o contrato central; a regra central não importa JpaRepository, HttpServletRequest ou anotações do framework.
O layout de pacotes é uma convenção, não a garantia. Um teste útil é compilar ou inspecionar dependências: a regra pode ser instanciada sem subir Spring? O caso de uso aceita um repositório de memória? O adaptador converte um objeto web para a entrada da aplicação sem levar detalhes HTTP para o domínio?
Cuidado com anotações no domínio
Se uma classe de domínio recebe anotação de persistência, esse detalhe pode parecer inofensivo até o domínio carregar regras e convenções do ORM. Avalie se essa dependência é aceitável ou se vale mapear entidades de persistência para tipos do domínio.
Recupere: o que faz o limite existir: o nome do pacote ou a dependência que o código realmente importa?
Material complementar da Fernanda
- DIP e injeção de dependência — Transfira a ideia para Java: o ponto de composição escolhe a implementação e a entrega ao caso de uso. A regra depende da interface; o construtor explicita como recebe o objeto. O trecho NestJS do guia não é necessário para este exercício.
Pratique com /aprender
/aprender Proponha pacotes Java para um caso de uso de matrícula com domínio, aplicação, HTTP e PostgreSQL. Peça que eu descreva as importações permitidas. Em seguida mostre uma dependência proibida do domínio para Spring e pergunte como removê-la.