Pelas Barbas do Coringa, é claro que Service Layer tem portas, Batman!

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 a um framework.

Durante todo tempo da relação código cliente X código consumido se corre 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 tem 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ínios 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 impede 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 domínio 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s