Introduzindo a camada de aplicação

Neste novo artigo sobre arquitetura de software, falarei sobre a camada de aplicação, suas principais características e alguns pontos a considerar para utilizá-la ou não.

Caso não tenha lido o <<artigo anterior sobre camadas>>, recomendo fortemente a leitura do mesmo para contextualizá-lo melhor.

O QUE É

A camada de aplicação (Application Layer) fornece um conjunto de serviços de aplicação (application services), os quais expressam as user stories (ou use cases) do software.

De modo simples, um serviço de aplicação recebe dados de seus clientes, como a interface de usuário, trata esses dados se necessário e chama um objeto do domínio para executar a operação de negócio.

Ele pode ainda fazer o controle de transação e tratar do controle de acesso do software, além de poder enviar notificações para outros softwares. Sendo assim, ele é um grande coordenador da operação de negócio a ser realizada pelo software e um cliente direto dos objetos de domínio.

(A camada de aplicação também é conhecida por camada de serviço (Service Layer), como mostrada no clássico livro Patterns of Enterprise Application Architecture do Martin Fowler.)

VISUALIZANDO NA ARQUITETURA CEBOLA

Abaixo segue como fica representada essa camada no modelo cebola:

Lembrando da regra de dependência entre camadas, a camada de aplicação conhece apenas a camada de domínio, sendo completamente ignorante a respeito de objetos e frameworks usados na camada mais externa. (Esse objetivo também pode ser atingido usando o Princípio de Inversão de Dependência, como mencionado no artigo anterior sobre camadas.)

UM PEQUENO EXEMPLO

Há várias formas de se implementar um serviço de aplicação, mas já dá para se ter uma noção de como ele é no código abaixo. Note que sequer estou tratando transações, por exemplo.

public class AtualizacaoDeEndereco
{
    private readonly IClienteRepositorio clienteRepositorio;

    public AtualizacaoDeEndereco(IClienteRepositorio clienteRepositorio)
    {
        this.clienteRepositorio = clienteRepositorio;
    }

    public void Executar(AtualizacaoDeEnderecoDto dto)
    {
        var cliente = this.clienteRepositorio.ObterPor(dto.IdDoCliente);
        var novoEndereco = new Endereco(dto.Rua, dto.Bairro, dto.Cep);
        cliente.AtualizarEndereco(novoEndereco);
    }
}

QUANDO USAR

Vamos a algumas perguntas:

– Existe mais de um cliente para uma determinada operação? Por ex.: duas interfaces gráficas ou uma interface gráfica e outro software.
– Existe apenas um cliente mas a operação é chamada em mais de um lugar, causando repetição de código?
– Existe alguma forma de integração entre uma operação e outros softwares, ou seja, parte da operação é realizada em outro contexto?

Se a resposta foi “sim” para pelo menos uma pergunta acima, é bem possível que a camada de aplicação seja uma boa ideia.

Agora vamos deixar de lado o “ter ou não ter” e focar na “intenção”. O que se espera com o software? Pretende-se mantê-lo vivo por muitos anos? Pretende-se facilitar sua manutenção caso haja troca de tecnologias de interfaces gráficas, bancos de dados ou outros serviços de suporte?

Novamente, se a resposta foi “sim” para as últimas perguntas, vale pensar com muito carinho no uso da camada de aplicação. Implementada de forma correta, junto com a camada de domínio, ela forma o núcleo do software, ou seja, tudo que ele se propõe a fazer, sem dependências de tecnologias e bibliotecas de terceiros.

Sendo assim, fica muito mais simples fazer a troca de toda a “periferia” com o surgimento de novas tecnologias.

QUANDO NÃO USAR

Implementar uma camada de aplicação (do jeito certo) pode ser algo trabalhoso, principalmente, se você nunca o fez. Exigirá um bom investimento.

Além disso, se você disse “não” a todas as perguntas da seção anterior, é possível que não valha a pena implementá-la. Pode ser que o software seja uma pequena aplicação com alguns CRUDs e nada mais (será? reflita…). Pode ser um mero “remendo” para uma solução maior a ser implantada e, portanto, será descartado em breve.

CONCLUSÃO

A camada de aplicação é uma boa forma de encapsular a lógica de aplicação, centralizando determinadas operações comuns, como o tratamento de transações.

Além disso, com o núcleo do software (aplicação e domínio) dependente apenas da plataforma da linguagem e nada mais (.Net, por exemplo), fica muito mais fácil evoluí-lo, já que o que mais muda ao longo do tempo são as tecnologias periféricas, como acesso a dados, interfaces gráficas, tecnologias de integração e serviços, etc…

É uma ótima opção para um software do qual se espera facilidade de extensão e longevidade.