A conceção orientada para o domínio é sobre o domínio. Os serviços de domínio e as fábricas de domínio não existem no domínio. Em geral, não os deve utilizar.
São construções artificiais, o que causa muitos problemas de compreensão do código, de manutenção e também de divergência entre o domínio, o modelo e o código.
Encapsulamos os casos de utilização do domínio em agregados de domínio, entidades e objectos de valor. Isto funciona bem para muitos casos de utilização. Mas quando um único caso de utilização envolve vários agregados, temos um problema.
Pode acontecer que um caso de utilização não pertença naturalmente a nenhum agregado. E é estranho quando um agregado contém a lógica de domínio de outro agregado.
Um serviço de domínio é um objeto de serviço sem estado. Encapsula um único caso de utilização que envolve mais agregados.
Temos uma loja eletrónica que contém carrinhos de compras e encomendas. A encomenda é um agregado bastante complicado, tal como o carrinho.
O caso de uso complicado é para encomendar o carrinho. Este caso de utilização envolve pelo menos dois agregados – carrinho e encomenda. Não pertence ao carrinho – o carrinho é uma caixa de compras que não é responsável pela encomenda. Não pertence à encomenda – a encomenda não se preocupa com a origem dos seus itens. Mas a conversão continua a ser um caso de utilização único.
A solução é um serviço de domínio que faz exatamente este caso de utilização complicado.
Não use serviços de domínio em demasia. Normalmente acabamos com um modelo anémico com comportamento em serviços. E isso não é a programação orientada a objectos.
Não misture serviços de domínio com serviços de aplicação, como deve saber. Os serviços de aplicação, tanto quanto sei, são algo da arquitetura da aplicação. Mas os serviços de aplicação estão numa camada diferente – a aplicação.
Penso que a confusão comum resulta do facto de ambos os tipos trabalharem com objectos de domínio.
Lembre-se de que o serviço de domínio não tem estado; ele não contém nenhuma propriedade privada. Os serviços de domínio são raros e contêm uma lógica de domínio complicada e agregada.
Já alguma vez viu como é feito o motor de um navio? Precisa de uma fábrica inteira para o fazer.
A fábrica é um objeto que produz agregados complicados ou, por vezes, também entidades e objectos de valor. Pode ser utilizado em vários cenários.
Se a construção do objeto for complicada, não há problema em transferir o processo de construção para uma fábrica separada em vez de utilizar um construtor complicado.
Se tivermos um repositório personalizado, podemos delegar a responsabilidade da reconstrução do objeto na fábrica. Por exemplo, se obtivermos dados JSON de uma API, passamo-los para uma fábrica e esta devolve um objeto de domínio.
Por vezes, a construção do objeto necessita de informações que não temos, como as informações de um sistema externo. A fábrica pode ser responsável por obter as informações necessárias e construir o objeto. No exemplo seguinte, obtemos o número de encomenda a partir de uma sequência externa.
As fábricas são muito utilizadas em excesso. O que normalmente precisamos é de um construtor.
O argumento de que novos objectos devem ser criados apenas em fábricas é estranho. Uma utilização típica da fábrica ou do padrão de fábrica abstrata é injectá-los para que possamos alterar a implementação. Este cenário é ótimo para IU onde não fazemos ideia se o sistema operativo é Linux, Windows ou qualquer outro.
Mas isso não é verdade na camada de domínio. Na camada de domínio sabemos exatamente qual a implementação que estamos a utilizar, é o objeto de domínio. Não é um objeto abstrato qualquer, é o objeto de domínio exato. E a única razão para alterar o objeto do domínio é uma alteração do domínio. Mas se o domínio mudar, nenhuma fábrica nos pode ajudar, temos de refactorizar o código.
Não as utilize.
EVANS, Eric. Conceção orientada para o domínio: abordar a complexidade no coração do software. Boston: Addison-Wesley, 2004. ISBN 0-321-12521-5.
