Afinal, para que servem camadas ?
Pelas Barbas do Coringa, mas é claro que pra separar as coisas, Batman!

Ao publicar um novo domínio em um software, estamos publicando uma caixa preta com objetivo específico, e adicionar uma Service Layer a esse domínio é controlar o acesso a essa caixa. Não só o que entra e o que sai, mas também o como esses domínio ira atender as necessidades de seus clientes.

Camada de serviço

A camada de serviço vai permitir que a demanda externa pelos algoritmos do domínio seja satisfeita sem criar problemas para o próprio domínio.

Eis por que eu digo “para o próprio domínio”: o código externo, ao acessar o domínio, é chamado de código cliente, e código cliente normalmente não está sob controle de quem escreveu o código do domínio que será utilizado.

Essa relação é muito clara entre o código da aplicação e o código do framework. A aplicação é cliente do código do framework, logo, o programador do framework não controla o código da aplicação e, caso o programador da aplicação queira mudar o framework, ele não poderá fazer isso, salvo se quiser perder o link com o framework original e lidar com as dificuldades de manter um fork. Já entre os domínios de uma aplicação, os desenvolvedores não costumam aplicar a mesma separação. Deveríamos ver cada domínio como uma ferramenta para realizar uma tarefa exatamente como um framework.

Durante todo tempo da relação código cliente X código consumido, corre-se o risco, normalmente declarado como fato impossível de evitar, de que os domínios se relacionem de uma maneira tão forte que a separação deixe de ser clara, e a isso damos o nome de acoplamento.

Quanto mais fácil a separação, menor é o acoplamento.

Esse é o ponto em que a camada de serviço entra. Como camada, ela separa o código cliente do código que é consumido, e essa separação se dá pela publicação dos recursos do domínio que são de interesse público. Pronto, nesse momento surge um muro entre o domínio e aqueles que quiserem consumir seu algoritmo e estão do lado de lá dessa parede. Esses clientes devem então usar os portões que estão abertos e seguir as regras necessárias para serem aceitos nesses portões.

Mas algo me incomoda na visão de um simples muro. Um muro controla o fluxo, quem entra, quem sai, por onde e quando, mas mesmo assim pessoas de fora entram. Vejamos assim: em uma relação entre dois domínios de código que precisam colaborar e fazem isso através de uma camada de serviço, existe o fato de que uma informação de um domínio precisa ser passada para outro para que o algoritmo possa ser aplicado. Um algoritmo existe para processar uma mensagem, e nesse momento surge um acoplamento entre os domínios e sua consequência, uma relação que restringe mudanças nos dois domínios.

Os dois domínios têm conhecimento de um objeto que representa a mensagem, e se um lado realizar uma alteração precisa comunicar o outro lado.

Claro que o risco de acoplamento e de efeitos colaterais de alteração em um dos domínios foi drasticamente reduzido com a Service Layer, mas ele ainda existe. Eis então que surge o escritório de fronteira.

Tradutores e fachadas (translators e facades)

Algo como naturalizar o imigrante antes que ele entre na cidade.

Os tradutores e fachadas são peças de software que cuidam para que um domínio se torne hermético. Cuidam para que o acoplamento exista até o portão e que uma mensagem que entre para ser processada seja reconhecida pelo domínio como uma mensagem de tipo definido internamente no domínio.

Dessa maneira, um domínio permite que a interface de comunicação com ele tenha contato com objetos estrangeiros de outros domínios, ou seja, que exista acoplamento que reflete em alteração na camada de serviço, caso o código cliente mude e impeça que esse acoplamento entre mais no código.

Cada domínio passa a cuidar de sua fronteira, e aquele que deseja abrir um diálogo com outro domínio é responsável pelo escritório de fronteira.

O que é ainda melhor é quando essa responsabilidade de tradução é assumida pelo código cliente. Nesse caso, o domínio cliente faz tradução de seu domínio para o que ele deseja consumir e acessa a service layer desse domínio, que faz uma checagem de seus próprios tipos. Assim, cada domínio passa a cuidar de sua fronteira, e aquele que deseja abrir um diálogo com outro domínio é responsável pelo escritório de fronteira.