Modelo de domínio anêmico

Resposta esperada

É quando as classes de domínio são só sacos de dados com getters/setters, e toda a lógica de negócio vive em classes de 'serviço' que operam sobre esses dados de fora. Parece organizado, mas joga fora a ideia central de OO — juntar dados e comportamento — e traz problemas: as regras que garantem a consistência de um objeto ficam longe dele, espalhadas por vários serviços, então é fácil um caminho de código esquecer uma validação; o objeto pode existir em estado inválido; e a lógica duplica. O contraponto (modelo 'rico'): o objeto `Pedido` tem `adicionarItem`, `aplicarCupom`, `fechar` — métodos que mantêm os invariantes — e o serviço orquestra casos de uso, não implementa a regra. Nem sempre é errado (às vezes a 'lógica' é mesmo procedural, ou o time usa outro paradigma), mas chamar de 'design OO' um modelo anêmico é enganoso.