Você deve ler mais sobre o Domain Driven Design . Basicamente, você tenta capturar os requisitos dos negócios em um modelo puro (na maioria dos modelos de objetos) que pode executar todas as tarefas lógicas de negócios necessárias. Esse modelo pode ser chamado a partir de uma camada de aplicativo (por exemplo, a visualização ou o controlador no MVC, no MVP você o chama e o ajusta para a GUI em um Presenter). O modelo também deve ser o mais ignorante possível sobre persistência e outras coisas técnicas.
Encapsular a lógica de negócios em um modelo de domínio como esse tem algumas grandes vantagens:
- Reutilização
- Facilidade de uso e extensão
- Geralmente leva a uma arquitetura melhor
- Comunica claramente as coerências e os requisitos de negócios ...
- ... e, assim, melhora a comunicação entre desenvolvedores, clientes, analistas, etc.
Eu recomendo o livro de Eric Evan sobre Design Orientado a Domínio para uma leitura mais aprofundada, pois ele irá direcioná-lo na direção certa e dar alguns bons exemplos de onde colocar qual lógica. Aposto que, quando você o ler, uma grande porcentagem de suas entidades conterá mais do que dados simples .
Mas estou achando difícil planejar uma abordagem na qual os Modelos lidem com a lógica de negócios e sejam classes que são completas em si mesmas.
Suponho que, por modelo, você esteja se referindo principalmente a entidades nesse contexto. Colocar a lógica / comportamento comercial nas entidades não é uma tarefa trivial. Mas você deve sempre pensar sobre o que uma entidade é eo que uma entidade faz . Tem algumas responsabilidades ou comportamentos? Às vezes, é bom ter entidades simples se comportamentos ou responsabilidades forem melhor expressos como serviços.
Suponha que você tenha um animal. Embora seus atributos possam ser salvos diretamente em um banco de dados, ele também possui algum comportamento. Precisa comer. Mas um herbívoro não come carne, então você precisa garantir que ele mostre seu comportamento quando o programador quiser que consuma carne à força. Ele pode se mover e fazer seu próprio ruído exclusivo. Essas são algumas coisas que devem ser modeladas na entidade, por exemplo. Você com certeza não confiaria em serviços procedimentais para fazer esses animais comerem, se moverem ou fazerem barulho.
Mas todos os exemplos são superficiais sem um domínio comercial concreto. Portanto, pense no domínio do seu negócio e em suas entidades, comportamentos e responsabilidades. Um outro domínio comercial pode conter entidades que se parecem muito com alguém de fora, mas são realmente algo completamente diferente ou mostram um comportamento totalmente diferente. O modelo precisa antes de tudo descrever o domínio de seus usuários o mais preciso possível.