quinta-feira, 10 de setembro de 2009

DDD: Enviar e-mail, onde vai esse negócio?

Já me deparei com essa pergunta em vários lugares e por isso mereceu um post no meu blog.

A resposta a essa pergunta é: Por que você precisa enviar e-mail?
Eu sei que é muito feio responder uma pergunta com outra pergunta mas nesse caso isso se faz necessário por que ela tem relação direta na solução do problema.

Geralmente eu sugiru como solução a criação de um serviço, mas eu percebo que as pessoas ainda não sabem direito como seria esse serviço e isso acontece por que a primeira coisa que vem a mente são os serviços de domínio;

No capítulo sobre “Services” do livro Domain-Driven Design: Tackling Complexity in the Heart of Software do Evans ele define os serviços da seguinte forma:

“This pattern is focused on those SERVICES that have an important meaning in the domain in their own right, but of course SERVICES are not used only in the domain layer. It takes care to distinguish SERVICES that belong to the domain layer from those of other layers, and to factor responsibilities to keep that distinction sharp.”

Ele deixa claro que podemos ter serviços em outras camadas fora a camada do domínio, mas ele ressalta a importância de se distinguir exatamente a atividade necessária para decidir o melhor local para o serviço.

Por exemplo, se para o seu envio de e-mail tiver envolvendo regras de negócio você provavelmente terá um serviço de negócio interagindo com um serviço de infraestrutura.

No livro Evans cita como exemplo o processo de transferêcia bancária. Após a camada de aplicação solicitar para a camada de domínio a transferência e obter confirmação que o processo foi realizado com sucesso, ela invoca um serviço da camada de infraestrutura para notificar os usuários envolvidos.

Resumindo, enviar e-mail é uma atividade de infraestrutura mas o motivo, ou negócio, influência diretamente na solução adotada.

quarta-feira, 9 de setembro de 2009

Boas práticas também serve para camada de interface sabia?

Quando falamos em padrões e boas práticas é muito comum pensarmos nas camadas de persistência, negócio, infraestrutura etc. Mas será que aplicamos esses mesmos princípios na camada de interface?
Alguns exemplos simples de como deixamos essas práticas de lado quando estamos trabalhando na camada de interface:


1) Preciso popular um ComboBox com uma lista de cidades. O procedimento mais comum nesse caso é o de "arrastarmos" o controle na tela, chamamos o método apropriado para trazer as cidades e preenchemos o controle com as cidades. Só que se tivermos 10 telas que precisamos exibir um ComboBox com cidades nós iremos repetir essa operação 10 vezes. Não teremos duplicidade de código? E se a forma de popular o ComboBox com as cidade por qualquer motivo tiver que ser alterada? Quanto tempo vamos ter que desprender para fazer essa alteração?

2) Muitas vezes precisamos gerar uma quantidade de código muito grande para tratar um determinado controle (TextBox, ComboBox, Button, etc...) e todo esse código fica misturado com o código de processo da tela (Cadastrar Cliente, Cadastrar Usuário, etc...). Se isolássimos o controle como um novo controle, será que não seria mais fácil a manutenção?

Com os recursos de interface rica, estamos produzindo cada vez mais código nas interfaces para proporcionar uma melhor experiência do usuário com o nosso sistema, e com isso também temos uma maior dificuldade em gerenciar esse código todo, por tanto, é cada vez maior a necessidade de se aplicar todos esses princípios e boas práticas na camada de interface.

Você já parou para analisar quanto tempo você desprende só para construir uma interface? Você já parou para analisar o quanto das alterações solicitadas pelo usuário estão diretamente ligadas a recursos de interface?

Utilizar MVC e criar controles personalizados são excelentes ferramentas para nos ajudar a gerenciar essa complexa estrutura que é a camada de interface, pense nisso quando estiver construindo suas interfaces.