Em um aplicativo DDD (Domain Driven Design) usando uma arquitetura em camadas convencional, a lógica de negócios entra na camada domínio . Agora, observe que essa camada não contém apenas as entidades de domínio ( Movie
, Review
), mas também serviços de domínio (como ReviewService
class) e repositórios. Então, ReviewService
também é uma classe de negócios.
Sua preocupação com cada cliente ter para usar o método de negócios apropriado ( addReview
) não é realista. Simplesmente não há nenhuma maneira prática de evitar que uma classe de clientes mal escrita viole regras de negócios, se os desenvolvedores não seguirem as regras da arquitetura escolhida. Por exemplo, se Movie
tiver um método getReviews()
(ou uma propriedade reviews
) que expõe uma coleção mutável de revisões, o código do cliente sempre poderá adicionar uma revisão arbitrária. E mesmo que seja imutável, o código do cliente sempre pode criar o Review
inválido no banco de dados usando diretamente um repositório.
Na minha opinião, é melhor ter apenas métodos de negócios relativamente simples em entidades de domínio e, geralmente, apenas para operações somente leitura. Uma lógica de negócios mais complexa é melhor atribuída a classes de serviço de domínio coesas. Caso contrário, suas classes de entidade se tornarão muito grandes e complexas. Assim, por exemplo, uma operação de negócios que adiciona um assunto de revisão de filme a regras de validação de negócios seria melhor colocada em uma classe de serviço de domínio ReviewMaintenance
ou até mesmo uma classe ReviewCreation
se a operação "adicionar revisão" fosse suficientemente complexa. / p>