09. Serviços de domínio e de aplicação

Este capítulo nasce das 30 questões publicadas sobre Serviços de domínio e de aplicação. A leitura do acervo revelou 30 núcleos de conhecimento, aqui reorganizados como uma explicação progressiva: primeiro o vocabulário e o modelo mental, depois os mecanismos, as decisões de implementação, os limites e a forma de verificar o comportamento do sistema.

Depois de entender o fluxo de desenvolvimento, aprofundamos a modelagem do negócio. O DDD organiza conhecimento, linguagem, limites e regras para que o software represente o domínio com clareza. Este é o capítulo 9 de 20 da disciplina Domain-Driven Design (DDD). Ele retoma Agregados e invariantes e utiliza essa base para avançar. Na sequência, estudaremos Eventos de domínio.

O fio condutor

O desenvolvimento de software começa com um problema e avança por decisões que precisam permanecer compreensíveis e verificáveis. Requisitos orientam modelos; modelos orientam código e arquitetura; testes verificam comportamento; e a operação devolve informações para o próximo ciclo. Uma falha importante no início tende a se espalhar pelas etapas seguintes.

Neste capítulo, use Serviços de domínio e de aplicação para acompanhar quatro perguntas: qual problema precisa ser resolvido, como o mecanismo funciona, que consequências a escolha produz e como o resultado será verificado. Essa sequência transforma termos técnicos em decisões que podem ser explicadas e testadas.

Parte 1 — Fundamentos e vocabulário

Começamos por Parte 1 — Fundamentos e vocabulário, pois essa base organiza os conceitos e exemplos que aparecerão no restante do capítulo.

Um serviço de domínio

O ponto de partida é estabelecer o significado do conceito e o problema que ele procura organizar. Um serviço de domínio representa comportamento pertencente ao domínio quando atribuí-lo a uma entidade ou a um objeto de valor produziria uma responsabilidade artificial. A operação deve ser expressa com termos da linguagem ubíqua e continuar pertencendo ao modelo, embora não tenha identidade ou estado próprio. Um cálculo de tarifa que dependa de conceitos provenientes de mais de um agregado pode justificar esse tipo de serviço. A ausência de um dono natural, e não a mera conveniência de agrupar código, é o critério decisivo. A regra ganha sentido quando suas consequências orientam a implementação.

Para aplicar Um serviço de domínio, acompanhe a execução desde a entrada até a saída e anote pré-condições, mudança de estado, custo e falhas possíveis. Assim o conceito deixa de ser um rótulo e passa a orientar decisões.

Use como teste da compreensão: Em Domain-Driven Design, uma operação de negócio relevante que não se encaixa naturalmente como responsabilidade de uma entidade ou de um objeto de valor pode ser modelada como serviço de domínio. Depois verifique a afirmação com execução controlada, teste automatizado, análise do contrato, medição ou documentação da versão correspondente. A evidência deve reproduzir a propriedade afirmada, inclusive nos casos de erro e de fronteira.

Serviços de domínio

A partir dessa distinção, o próximo elemento completa o fluxo. Serviços de domínio são concebidos como operações sem identidade e sem ciclo de vida de estado próprio. Seus resultados podem depender dos argumentos recebidos e de colaboradores explicitamente utilizados, como uma política ou um repositório abstraído pelo domínio. Ser stateless não significa ser incapaz de solicitar uma alteração persistente; significa não conservar internamente estado empresarial entre invocações. Quando o estado e sua continuidade são essenciais ao conceito, uma entidade ou um objeto de valor costuma ser uma modelagem mais apropriada. Observe como definição, mecanismo e efeito permanecem ligados.