Onde colocar as minhas regras de negócio?

A resposta é…. Depende! rs

Se você escolheu utilizar DDD no seu projeto é porque você conhece e já isolou o problema a ser resolvido que, por ser complexo, será baseado em um modelo, recebendo o foco e a prioridade necessárias para a solução deste domínio. Quando você isola este domínio, obviamente você deve encapsular tambem todas as regras de negócio dentro desse domínio.

Para exemplificar melhor vamos fazer a seguinte funcionalidade de exemplo no nosso dóminio.

Todos os pedidos com valor acima 1.000,00 e que são pagos com dinheiro em espécie são elegíveis a um desconto de 10% por produto.

Claro que esta informação tem que ser passada para o usuário final do sistema, mas é responsabilidade do sistema checar se as informações passadas estão corretas. Você pode até colocar a regra de validação tambem na camada de apresentação ou dentro do seu banco de dados em forma de triggers (argh, rs!), mas de qualquer maneira o domínio tem que ter esta validação, já que um dos princípios do DDD é justamente poder trocar a camada de apresentação sem que o domínio seja alterado ou compartilhar o mesmo domínio entre interfaces/sistemas diferentes.

Portanto, segue a primeira afirmação:

Por mais que a sua camada de apresentação faça as regras necessárias para uma determinada funcionalidade, o seu domínio tambem deve, obrigatoriamente, fazer com que estas regras estejam presente internamente, tornando-o coeso da camada que ele comunica.

Vamos melhorar este exemplo mostrando como ficariam as entidades envolvidas nesta funcionalidade.

public class Pedido {
	private List<ItemPedido> itens;
	private BigDecimal precoTotal;
	//Acessores omitidos
}
public class ItemPedido {
	private Produto produto;
	private BigDecimal precoVenda;
	private BigDecimal desconto;
	//Acessores omitidos
}

OBS.: Muitos podem perguntar porque a informação referente ao preço final é um atributo da classe e não um comportamento da entidade (um método que poderia somar todos os preços finais decrementando os descontos dados por cada produto, multiplicado pela quantidade de cada produto). Vamos pensar que o preço do Produto pode – e deve – variar e o sistema precisa manter a informação do preço de venda naquele momento, ok?

Eu encaro que esta regra de negócio deve estar em uma checagem no momento da inclusão, como por exemplo uma Specification destinada somente a esta regra. Lembro que, a Specification tem, neste caso, o intúito de validar uma informação e que ela não precisa ser necessariamente apenas uma única specification. Eu posso – e é até melhor – dividir a informação em várias Specifications, uma para cada regra de negócio que a minha funcionalidade exige.

Vamos pensar então que a minha classe ValidarDescontoDadoSpecification tem o seguinte código:

public class ValidarDescontoDadoSpecification
	implements Specification<ItemPedido> {

	public static final BigDecimal DESCONTO_MAXIMO_PGTO_DINHEIRO = 10;

	public boolean isSatisfiedBy(ItemPedido item){
		if(itemPedido.getFormaPagamento.equal(FormaPagamento.DINHEIRO){
			BigDecimal descontoDado =
				Calculadora.percentualEntre(
					item.getPrecoVenda(),
					item.getDesconto());
			if(descontoDado.compareTo(DESCONTO_MAXIMO_PGTO_DINHEIRO) > 1){
				//É necessário comunicar ao domínio o porque da falha
				//Neste caso, leia mais sobre Notification
				return false;
			}
		}
		return true;
	}
}

Pensando que você sempre salva o pedido, poderiamos ter uma outra Specification para isso, conforme abaixo:

public class PersistirPedidoSpecification
	implements Specification<Pedido> {

	public boolean isSatisfiedBy(Pedido pedido){
		/*
		  As boas maneiras de aplicativos internet diz que
		  vc deve validar tudo de uma unica vez, rs
		*/
		boolean resultado = true;

		//Validações referente ao Pedido

		ValidarDescontoDadoSpecification spec =
			new ValidarDescontoDadoSpecification();
		for(ItemPedido item : pedido.getItens()){
			if(!spec.isSatisfiedBy(item)){
				/*
				  Lembre que a informação da falha deve ser feita
				  pela outra Specification, não por esta!
				*/
				resultado = false;
			}
		}
		return resultado;
	}
}

Assim, no final de tudo, nós poderiamos ter no repositório Pedidos, o seguinte código:

public class Pedidos{

	public static void persistir(Pedido pedido){
		PersistirPedidoSpecification spec
			=  new PersistirPedidoSpecification();
		if(spec.isSatisfiedBy(pedido){
			dao.salvar(pedido);
		} else {
			//Comunica a falha encontrada às outras camadas
		}
	}
}

Espero ter ajudado!!!

Abraço a todos!!!

Comente e Recomende!!

Mais uma vez, muitos podem ser os fatores que atrapalham um bom levantamento. Analistas inexperientes, hierarquias mau definidas, credibilidade da equipe, clima hostil com o cliente, falha de detalhamento – muito ou pouco, dependendo do caso, usuários indecisos, usar “o que já existe” como exemplo e o pior de todos: usuários “acostumados” com o erro.

Recentemente, estou trabalhando como bombeiro em um projeto que espelha muito do dito acima.

A proposta era redesenhar um sistema originalmente feito em Delphi, que já funcionava a alguns anos para uma estrutura web em Java que temos. Este sistema já tinha passado por diverss atualizações, transformando o código em uma bela macarronada

Por uma briga que se arrasta a gerações (rs), há um clima hostil entre o gerente de projetos e o cliente final (que não cabe a mim questionar, muito menos entender). Isso gerava muitas discursões (infinitas até) quando se queria definir algum ponto.

Dica 1:Quando o manifesto ágil diz para ter o cliente como parte da equipe não é so ter o cliente por perto, mas sim jogando no mesmo time.

Quando se senta para definir alguma coisa, quanto mais gente entendendo, melhor! Entendendo não significa estar falando ou questionando. Mas todas pessoas precisam ter o mesmo entendimento. Por muitas vezes na reunião, surgia uma pergunta que não tinha fundamento algum, como se a pessoa estivesse voando ou não entendendo nada do que estava acontecendo.

Dica 2: Nunca deixe uma duvida no ar. A reunião é justamente para atender as necessidades dos analistas. Preste atenção quando alguem fala para poder perguntar alguma coisa válida. E questione se não entender! Sempre!

Para piorar, o gerente teve uma das piores atitudes que se pode tomar em uma reunião de levantamento: proibir os analistas de perguntarem, fazendo ele um funil com o cliente. Esta atitude fez com que conceitos fossem perdidos e o pior, conceitos errados surgiram.

Dica 3: Para um projeto, hierarquias não devem existir. Claro que algumas vozes pesam mais do que outras mas no momento de levantamento, todos devem ser ouvidos.

Então começa a definição dos casos de uso. Envolvidos em conceitos errados, climinhas e muita briga, os analistas ‘copiaram’ as funcionalidades do sistema antigo sem propor nenhuma alteração. Na aprovação do documento de requisito (aqui nós temos esse passo, por enquanto, rs) o usuário reclamou de muita coisa que estava definida ali, dizendo que se fosse par ter a mesma coisa, que continuasse com o antigo.

Dica 4: O legado pode ser usado como exemplo, mas tente sempre surpreenda o cliente com alguma novidade. Pense no que pode melhorar o trabalho dele e proponha modificações, sempre embasadas em alguma teoria, por mais simples que seja.

Troca-se a equipe para dar mais força ao projeto. Com isso, o usuário já não acreditava na equipe anterior, achando que eles poderiam novamente fazer as besteiras feitas anteriormente.

Dica 5: Por mais que fosse necessária a colocação de mais recursos, nunca deixe a credibilidade da equipe em risco. Se você não acredita no vendedor, como vai comprar o produto?

A nova equipe começou a detalhar – novamente – as funcionalidades e as mesmas tiveram variações, fazendo com que coisas com pouco detalhe tivessem uma pontuação de ‘codificação’ errada diante de tantos detalhes e outras que realmente tinham um alto grau de dificuldade, com pontuações baixas diante da falta de detalhamento.

Dica 6: Detalhe somente o necessário. Incremento é justamente isso! Se Quando chegar o momento você aumentará o nivel de detalhe.

Dá pra sentir como foi a fase de desenvolvimento deste projeto, né?!

Fazendo uma analogia com a construção de uma casa, a reunião de apresentação dos requisitos e das datas de entrega foi mais ou menos assim.

Analista: (…) Então aqui nós teremos os 3 quartos necessários.
Usuário: Mas eu não preciso de 3 quartos. Eu preciso de 3 camas!
Analista: Sim mas nós colocamos 3 quartos distintos para uma melhor modularização. Sem contar que esse quarto maior aqui é uma suite.
Usuário: Mas nesse quarto aqui, alem de ser suite, ele precisa de uma cozinha.
Analista: Como assim uma cozinha? Já existe uma cozinha aqui, veja!
Usuário: Mas eu preciso de uma cozinha aqui porque na antiga casa eu tinha uma cozinha perto da cama.
Analista: Sim, mas agora nós temos quartose a cozinha em ambientes separados.
Usuário: (…) E onde está a minha janela dos fundos para eu entrar?
Analista: Agora nós temos uma porta aqui nos fundos.
Usuário: Está errado. Funcionava assim: eu entrava na casa, abria a janela, saia da casa, dava a volta na casa, entrava pela janela e acessava a parte dos fundos da casa.
Analista: Agora você não vai precisar fazer isso. Nós temos uma porta para que você entre diretamente por ela, já que o proposito é apenas entrar na casa.
Usuário: Não o proposito é entrar na casa pela janela. E janela não é porta. A porta é pra entrar pela frente, a janela é para entrar pelos fundos.

Dica 6: Para o usuário que está acostumado com o erro do software antigo (que para ele já é trivial “entrar por uma janela”), você precisa mostrar e provar para o usuário que se é para entrar, precisa ser por uma porta.

Como dizia meu avô…

Burro não aprende, burro acostuma.
Não faça do seu usuário um burro.

Comente e Recomende!

Em qualquer sistema OO, vc trabalha com….. objetos (ohhhhhhhh)

Qualquer objeto ‘precisa’ ser….. criado antes de ser utilizado…. (ohhhhhhh)

Qual a melhor maneira de se criar objeto? (errr…. humm….. bem…….)

Muitas são as maneiras… usando um construtor, por DI (Dependency Injection), por fábricas, etc.

O mais utilizado são as fábricas, ou Factories conforme catalogado pelo GoF, ou Gang of Four.

Resumidamente, “o padrão Factory fornece uma interface para a criação de famílias de objetos correlatos ou dependentes sem a necessidade de especificar a classe concreta destes objetos”.

Diversos exemplos de fábricas existem espalhados pela internet, e eu não vou colocar mais um aqui. Procure, rs!

A motivação inicial do padrão era a criação de objetos complexos, fazendo com que a lógica estivesse toda em um unico lugar… princípio de DRY nos promórdios da Arquitetura de Software!

Porém, certos objetos alem de serem complexos, precisavam de um processo de construção demorado. Algumas tecnicas para a sulução deste problema era ‘reter’ o objeto contruido e utilizá-lo como um ponto de acesso único, otimizando assim o processo de construção.

Com isso, por muitas vezes os desenvolvedores juntavam dois padrões de projetos para sanar o problema de contrução complexa e demorada, utilizando Factory e ‘Singletons’ para colocar objetos a disposição do ‘domínio’.

Colocar fábricas a disposição dos desenvolvedores, por muitas vezes, mascarava onde realmente estes objetos deveriam ser criados. Poderiam existir inúmeras fábricas em um único projeto, como eu já presenciei num passado não muito distante. Era DaoFactory pra cá, AbstractDaoFactory pra lá, ReportFactory aqui e ServiceFactory acolá! Uma verdadeira macarronada de factories!

Então, como manter um ponto único de acesso para ‘encontrar’ os objetos?

Fowler resolveu colocar tudo em um unico padrão e o nomeou de Registry, ou Registro.

De acordo com Fowler, Registry é

Um objeto conhecido que outros objetos podem usar para encontrar objetos e serviços comuns.

A função do Registro é:

1. Criar objetos
2. Encapsular complexidades de criação
3. Reter objetos criados
4. Funcionar como ‘local dos objetos’

Com isso, se você quizer saber ou precisar de um objeto e o seu sistems tem um Registro, pergunte a ele!

Normalmente os Registros são factories e singletons mesclados, conforme o exemplo abaixo:

public MyDomainRegistry{
    private static MyDomainRegistry INSTANCE = null;

    private MyDomainRegistry(){
        loadVariables();
    }

    private static MyDomainRegistry instance(){
        //Coloque aqui a sua implementação de Singleton
        return INSTANCE;
    }

    //Posso usar SubDomains
    private ConsultarSubDomain consultarSubDomain;
    //Posso usar Services Services
    private ConversaoService conversaoService;
    //Qualquer objeto que eu queira localizar!
    private MyRepository myRepository;

    private void loadVariables(){
        //Aqui vc deve criar os seua objetos como achar melhor
        this.consultarSubDomain = new ConsultarSubDomain();
    }

    //Aqui vc coloca os métodos estáticos para retornar
    //os objetos que o registro precisa controlar
    public static ConsultarSubDomain consultarSubDomain() {
        return instance().consultarSubDomain;
    }
}

Bem simples, não?

Agora, para você utilizar um objeto, basta solicitar ao registro, assim.

public class FachadaDoDominio {

    private FachadaDoDominio() {
    }

    public static ConsultarSubDomain consultar(){
        return MyDomainRegistry.consultarSubDomain();
    }
}

Comente e Recomende!

O conhecimento hoje é uma jóia que está a apenas alguns cliques de todos nós. Hoje em dia se aprende desde a fazer arroz a até uma bomba nuclear. Mas como adquirir conhecimento na nossa área? Como programar melhor? Como otimizar o seu tempo de desenvolvimento? Muitas dessas respostas estão a disposição de todos os programadores desde o inicio do ano 2000, numa das melhores -senão a melhor – compilações de boas práticas para a área de desenvolvimento de software.

Trata-se do livro The Pragmatic Programmer, From Journeyman to Master, de Andrew Hunt e David Thomas. Eu já li o livro pelo menos umas duas vezes (falando nisso, preciso entregar o livro ao dono!) e recomendo a quem não leu ainda, seja ele junior ou sênior.

O livro traz uma série de dicas sobre como se tornar um bom programador. Segue um pequeno resumo.

1. Preocupe-se em fazer um código bom
2. Pense!! Critique o seu trabalho
3. Dê opções, não dê desculpas.
4. Conserte falhas ao encontrar a falha
5. Seja um catalizador de mudanças
6. Lembre-se o ‘porquê’ do projeto
7. Faça da qualidade um requerimento
8. Invista regularmente no seu portifólio de conhecimento
9. Analise e critique o que você ouve e vê
10. É o que você fala e COMO você fala
11. DRY – Don’t Repeat Yourself
12. Faça facil para ser reutilizavel
13. Elimine efeitos entre coisas não relacionadas
14. Não existem decisões finais
15. Use traçantes para achar o alvo
16. Prototipar para aprender
17. Programe para o problema do domínio usando a linguagem do domínio
18. Estime para evitar supresas
19. Itere o cronograma com o código
20. Deixe o conhecimento em arquivos textos
21. Use o poder das linhas de comando
22. Use BEM apenas um editor
23. Sempre use um controlador de versão
24. Resolva o problema, não a culpa
25. Não entre em pânico ao debugar
26. O problema normalmente não é no ’select’
27. Não assuma algo, prove!
28. Aprenda uma linguagem de manipulação de texto
29. Excreva código que escreva código
30. Não, você não pode escrever softwares perfeitos. Proteja o seu código.
31. Desenhe soluções baseadas em contratos
32. Pegue os problemas precocemente. Teste desde o inicio.
33. Use asserções para prevenir o impossivel
34. Use exceções apenas para o excepcional
35. Termine o que começou
36. Minimize acoplamentos entre módulos
37. Configure! Não integre!
38. Coloque abstração no código e detalhe no metadata
39. Analise o workflow para melhorar a concorrências
40. Desenhe usando serviços
41. Sempre desenhe pensando em concorrência
42. Separe a visão do modelo
43. Desenhe e conheça o fluxo da informação
44. Não programe por concidência
45. Estime a complexidade dos seus códigos
46. Teste as suas estimações em unidades reais
47. Refatore frequentemente, agora e sempre!
48. Desenvolva para os testes
49. Teste o seu software, ou os usuários testarão
50. Não use geradores de código que você não entenda o que foi gerado
51. Não apenas leia os requisitos. Mergulhe neles. Escave eles!
52. Trabalhe com um usuário para pensar como um usuário
53. Abstrações sobrevivem mais do que os detalhes
54. Crie um glossário de projeto
55. Ache, pense e pese as ‘necessidades’
56. Comece quando estiver pronto!
57. Algumas coisas são melhores prontas do que descritas
58. Não seja escravo da formalidade
59. Ferramentas caras não produzem as melhores arquiteturas
60. Organize o time por funcionalidades, e não por funções.
61. Automatize o que puder ser automatizado.
62. Teste frequentemente e automaticamente
63. Só está pronto quando o teste roda com sucesso
64. Use sabotadores para testar o seu teste
65. Não teste apenas o código. Teste as situações do domínio
66. Ache erros apenas uma vez
67. Escreva documentos com os mesmos princípios que vc escreve código
68. Não separe tanto a documentação do código
69. Exceda a espectativa do seu cliente
70. Assine o seu trabalho

PS: Qualquer duvida, só comentar que eu detalho os itens.

Comente e Recomende!!

Felicidade de ver todo um trabalho ganhar repercussão nacional, aparecendo numa mídia de alto nível e o melhor, falando muito bem!
Por outro lado, mais uma vez, quem realmente fez isso acontecer, não apareceu…
Não tirando os méritos dos lideres, que existem, mas acho que ao menos um “graças aos nossos colaboradores” nós mereciamos. Mas faz parte. Uns fazem, outros aparecem.

Estou falando dessa matéria do jornal O Globo, do caderno de tecnologia (não se tem que estar cadastrado, mas é free).

Quatro projetos envolvendo alta tecnologia no combate e no controle do câncer estão em andamento no Rio e no Brasil. E, ao contrário do que possa parecer, trata-se de projetos de âmbito público, não privado, todos a cargo da Fundação do Câncer, que desenvolve as iniciativas para apoiar o Inca (Instituto Nacional de Câncer), hospital de referência na área, na Praça da Cruz Vermelha.

Além da simpatia da equipe, trabalhar no INCA tem um apelo que pouquissimas empresas pode trazer, que é a parte social dos produtos finais. Afinal, não estamos aqui para trazer mais clientes, pelo contrário, quanto menos melhor! Não queremos ganhar dinheiro com os produtos, pelo contrário, todas as ferramentas são para um fim privado, que indiretamente gera um valor agregado muito grande para o INCA.

Não é como trabalhar aqui ou ali, onde tudo o que é desenvolvido e criado é visando dinheiro, lucro, clientes, posições, alianças, opniões, etc. Se você pensar no resultado do produto, no fundo, estamos ajudando a muitas pessoas!

Portanto, gostaria de agradecer a todos os que trabalharam nestes projetos que me orgulho de ter, de alguma forma, ajudado a construir.

Projeto QID – Qualidade da Interpretação Diagnostica

O primeiro projeto é o desenvolvimento de um sistema para unificar as informações sobre os exames – e consequentemente diagnósticos – do câncer de mama no país.

Elizabeth Ribeiro da Silva
Evandro Ribeiro Gomes

Projeto BPW – Base de Registro Populacional de Câncer

Outra frente em que a tecnologia ajudará é uma espécie de “censo” da incidência de diferentes tipos de câncer na população brasileira.

Pedro Paulo dos Santos
Elaine Cristina Soares Nunes
Tiago Ribeiro de Azevedo
André Luiz Guedes

Projeto RBTMO – Registro Brasileiro de Transplante de Medula Óssea

O terceiro projeto envolvendo tecnologia e câncer diz respeito a transplantes de medula.

Shiela de Oliveira Prado
Filipe André Paes Souza

Projeto AD – Assistência Domiciliar

Finalmente, o quarto projeto usa a tecnologia dos telefones celulares para uma missão nobre: dar mais conforto a pacientes em estado terminal.

Anderson Ambrósio
Wagner Shimatai

Parabés a todos pela conquista!!!

Revisão de código

Sempre me perguntei:

“Como vou deixar claro pra uma pessoa no futuro que o que eu pensei foi asssim, e não assado sem usar somente a documentação?”.

Normalmente, em equipes heterogêneas no carater de senioridade, as solições podem pensar bastante diferente, fazendo com que só a documentação não seja suficiente. E esse cenário de equipes heterogêneas é o mais comum em ambientes de fabricas, onde se misturam plenos – chamados de seniors – com estagiários – chamados de juniors. Então, por ser um processo requerido – por exemplo no CMMi – um pleno desenvolve e um estagiário revisa.

Caso Veridico

Esse lance de revisão me lembra um caso acontecido com um grande amigo meu.

Lá no inicio de vida, a ‘tia’ avisa que fará o ditado do emprego de L e do U, mas que haverá uma surpresa na correção, que será feita pelo coleguinha ao lado. Pois bem, começou o ditado e André foi escrevendo:

1. Salto
2. Alto
3. Saudade
4. …

Ao fim, a professora pede pra trocar com o coleguinha ao lado e André troca com o seu amiguinho Filipe (nome fictício). Ao começar a ver o ditado, André percebe que Filipe inverteu todos os empregos de U x L, colocando Sauto, Auto, Saldade, etc. Com isso, André começou a dar errado em cada item do ditado, fazendo com que Filipe ficasse com zero. André entrega a prova a Filipe e recebe a sua. Ao ver o seu ditado, André fica indignado! Filipe corrigiu tudo como escreveu (Sauto, Auto, Saldade) dando zero para André tambem! (É mais engraçado ele contando…)

Conclusão: Pessoas de niveis diferentes não conseguem estabelecer um nivel de revisão satisfatório.

Programação em Par

Já na programação em par (Pair Programming) as duas pessoas estão no mesmo momento desenvolvendo o código, fazendo com que a conversa, as duvidas e as soluções faça o código sair da melhor maneira possivel para as duas pessoas, evitando retrabalho.

Moral da História: se fosse um ditado em par, de repente, Filipe aprenderia mais rapido e as notas seriam melhores na turma toda.

Obs.: Um ótimo post da InfoQ-Br.

Contrato nada mais é do que vc garantir que o que entra no domínio está valido e o que sai está de acordo com o que o método se propõe a fazer! Retirado do Wiki do Phillip…

Se quem chamar me garantir a pré-condição, eu garanto a pós-condição.

Garantir a pré-condição é garantir que todos os parâmetros que vc precisa (e recebe) para efetuar uma ação estejam de acordo com uma especificação mínima. Com isso, a pós-condição – que é a sua resposta do método (retorno) – estará garantida.

O padrão utilizado neste caso – para criar uma camada de comunicação do domínio com o mundo – é o Facade (leia-se “Fasseide”, “conjuncão de Face + ade”), um padrão de projeto citado no livro Design Patterns: Elements of Reusable Object-Oriented Softwares, da Gang of Four [Gof]. Ele cita o seguinte:

Fornece uma interface unificada para um conjunto de interfaces em um subsistema. Façade define uma interface de nivel mais alto que torna o subsistema mais facil de ser usado.

A motivação básica desse padrão é dividir sistemas em subsistemas para reduzir a complexidade do código.

Como eu falei anteriormente, um padrão pode ser desenvolvido de diversas maneiras, mas algumas implementações são tão simples que são frequentemente copiadas ao longo dos projetos. A implementação mais comum de Facade é ter um construtor privado – para impossibilitar a criação de uma instancia da classe -  e colocar os métodos da facade como estáticos. Veja o exemplo:

public class Facade {

    private Facade(){
    }

    public static String sayHello(){
        return "Hello World!";
    }
}

Dentro do seu método, vc pode perfeitamente trabalhar da maneira que melhor imaginar, porem, não convem colocar nenhuma regra de negócio ou validação dentro da facade, já que um método interno do domínio pode referenciar outro método do domínio sem necessariamente passar pela facade.

Existem tambem quem utilize uma classe para fachada, criando outras classes mais especificas para controlar cada ação, dividindo o sistema em sub-dominios, chamados por uma mesma fachada.

Blindar e validar sem ter regra de negócio? Para organizar melhor esta bagunça, Martin Fowler e Erick Evans desenvolveram o padrão Specification.

[...] business logic can be recombined by chaining the business logic together using boolean logic.

OBS.: Aqui está o PDF de Fowler sobre Specification.

Com a Specification, vc pode validar, selecionar e até mesmo construir objetos-modelo para satisfazer a sua regra de negócio. Mais uma vez, nenhum padrão tem uma implamentação fixa, todas podem variar, mas a mais utilizada para Specification em Java é a seguinte:

public interface Specification<T> {
    boolean isSatisfiedBy(T t);
}

No exemplo acima, ela retorna true ou false, caso o objeto passado esteja de acordo com a especificação. Esta especificação ainda pode ser de vários tipos, conforme alguns exemplos descrito abaixo:

public abstract class AndSpecification<T> implements Specification<T>{

    private final Specification<T> one;
    private final Specification<T> other;

    //Retorna true se o objeto passar pelas duas especificações
    public AndSpecification(Specification<T> one, Specification<T> other) {
        this.one = one;
        this.other = other;
    }

    public boolean isSatisfiedBy(T t){
        return one.isSatisfiedBy(t) && other.isSatisfiedBy(t);
    }
}

public abstract class OrSpecification<T> implements Specification<T>{

    private final Specification<T> one;
    private final Specification<T> other;

    //Retorna true se o objeto passar por uma das duas especificações
    public OrSpecification(Specification<T> one, Specification<T> other) {
        this.one = one;
        this.other = other;
    }

    public boolean isSatisfiedBy(T t){
        return one.isSatisfiedBy(t) || other.isSatisfiedBy(t);
    }
}

public interface SelectionSpecification<T> {
    //Filtra uma lista de acordo com uma especificação
    List<T> isSatisfiedBy(List<T> list);
}

Utilizando o nosso exemplo, vamos criar um exemplo para validar o cadastro de um usuário:

public class CadastrarUsuarioSpecification
    implements Specification<Usuario> {

    public boolean isSatisfiedBy(Usuario usuario) {
        if(usuario.getNome().equals("") ||
           usuario.getSenha().equals("") ||
           usuario.getLogin().equals("")){
            return false;
        }
        return true;
    }
}

OBS.: Lembrando que isso é apenas um exemplo didático, a entidade usuário do exemplo tem mais campos para serem validados!

O Dominio deve ter a sua validação independente do que vc utilize fora dele, seja Client-side com JavaScript ou Server-Side no seu servlet, por exemplo. Sempre faça o Design By Contract valer no seu domínio.

A especificação CadastrarUsuarioSpecification deve executar todas as validações necessárias para a inclusão de um usuário na base de dados. Utilizando-a em conjuntio com a Facade, teriamos algo como:

public class Facade {

    private Facade(){
    }

    public static void cadastrar(Usuario usuario){
        CadastrarUsuarioSpecification spec =
            new CadastrarUsuarioSpecification();
        if(spec.isSatisfiedBy(usuario)){
            //Cadastrar usuario
        } else {
            //Levantar erro!
        }
    }
}

Com isso, isolamos o domínio, garantimos o contrato e o seu domínio está vacinado conta possiveis erros vindo de outras camadas!

P.S.: Para o conceito de Specification não ficar vago, ainda existem muitos modelos de se contruir uma especificação, seja ela para acesso a banco, para colecionar critérios, para gerar um SQL, para filtrar uma lista, etc. O que precisamos ter em mente é que sempre que vc quizer implementar uma regra de maneira clara, procure ver antes se ela se encaixa em uma specification.

Até!

comente e Recomende!

Entidade é um objeto com um significado para o domínio sendo modelado e que possui uma identidade.

Diagrama de Classe extraido do Modelo

No exemplo dado no decorrer da série de post, basicamente, estas seriam as nossas entidades. Repare que todas as classes possuem uma identidade (o campo ID de cada classe). Isso define uma Entidade: a sua identificação única!

Modelo de dados extraido do Diagrama de Classes

Pensando em um modelo relacional, basicamente, cada entidade representa um registro de uma tabela e as suas referências e dependências. Mas preste a atenção: um modelo relacional é diferente de um modelo de entidades, já que existem diferenças em cada mundo. Veja, por exemplo, a tabela Workflow: não existe referencia a ela como uma classe, mas existe uma coleção, dentro da entidade de Status que referencia esta associação.

DTO x TO x VO x Entidade x Pojo x JavaBean

Vc já ouviu falar de DTO (Data Transfer Object), correto?
E de TO (Transfer Object)?
E de VO (Value Object)?
E de POJO (Plain Old Java Object)?
E de Java Bean?

Se vc acha que é tudo a mesma coisa, vc está enganado!

TO foi citado pelo grupo Core J2EE Patterns inicialmente e foi desenhado para ser usado quando aplicações precdisam se comunicar com EJBs, reduzindo a quantidade de métodos a serem chamados.

DTO segue um proncípio parecido, só não cita EJB e foi descrito por Martin Fowler.

Básicamente, TO e DTO são a mesma coisa, um monte de campos com um bando de métodos acessores (Get e Set) para trafegar informação entre dois “extremos”.

Fowler ainda vai adiante e escreve:

Data Transfer Object is one of those objects our mothers told us never to write. It’s often little more than a bunch of fields and the getters and setters for them. The value of this usually hateful beast is that it
result you need to reduce the number of calls, and that means that you need to transfer more data with each d to procall. One way to do this is to use lots of parameters. However, this is often awkwaronly a single value.often impossible with languages such as Java that return The solution Mels How It Works In many ways, amore than a bun
allows you to move several pieces of information over a network in a single call?a trick that’s essential for
tributed systems.

Já o padrão VO é como se fosse um DTO imutável, ou seja um objeto que mantem o seu valor no decorrer da sua vida. O número 5 sempre vai ser 5. Quando vc muda o 5 pra 6, ele deixa de ser o número 5 e vira o numero 6. Número neste caso é um objeto de valor, um é diferente do outro. Em Java, String, Date, todos os Number. Normalmente

Fowler define Value Object como:

A small simple object, like money or a date range, whose equality isn’t based on identity.

VO não tem identidade, tem valor!

Já o POJO, cunhado por Martin Fowler e cia, são objetos simples. São aqueles objetos que não enxtendem ou implementan ninguem. Não dependem de nenhuma atividade externa. São objetos simples que utilizam somente códigos “nativos de Java”.

E Java Bean? Bem, Java Bean é uma especificação! É ela que diz que as classes devem começar com letra maiúscula, os métodos em minúscula, os getX, setX e isX da vida..

Resumindo:

• Pojo são simples objetos puramente Java;
• JavaBean é uma especificação;
• DTO = TO = Objeto pra transferência de informação;
• VO é um DTO que mantem o seu estado
• Entidade é um objeto que tem uma identidade em um domínio.

Até!

Comente e Recomende!

Christopher Alexander, um renomado arquiteto italiano, uma vez citou:

Cadas padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que vc possa utilizar usar esta solução mais de um milhão de vezes, sem nunca faze-lo da mesma maneira.

Christopher Alexander não construia sistemas. Ele construia prédios, casas e cidades. Mas a citação acima se encaixa perfeitamente na definição de padrão de projeto para construção de sistemas! São soluções para um problema conhecido! Não adianta saber “fazer” um padrão de projeto. Vc precisa identificar o problema e achar a melhor solução para este problema, seja ela conforme o criador do padrão de projeto citou ou como você achar melhor. Basta que a definição do padrão seja seguida na sua implementação. Portanto, não grave como a sua classe deve ser para atender um determinado padrão, grave o que o padrão prega, o que ele se propõe a solucionar e os principios de design do padrão.

Outro grande problema encontrado é quanto a nomeção de classes. Quando se nomeia uma classe, deve-se deixar bem claro (porem sem termos um texto como nome) o que a classe faz e como ela foi idealizada. Não só com comentários, mas com os nomes claros, deixando-os entendíveis a primeira vista.

Essa é outra motivação dos padrões. A nomeação é tão importante como a sua implementação. Não adianta vc definir um padrão extremamente bem se uma pessoa que vai desenvolver utilizando essa classe, não conseguir enchergar o que ela realmente faz.

Imagine que vc está entrando em um projeto agora e ao abrir o seu workspace, se depara com uma Classe chamada ConfiguracaoSingleton. Automaticamente vc saberá que se trata de uma instância única da configuração da aplicação.

Ter expressividade no seu código é 80% de um código bem feito! Se alguem entende o que vc se propoz a fazer, as possiveis correções e manutenções (ou até mesmo, usar o seu código como exemplo) fica muito mais facil.

Portanto nomeie bem seu código e saiba o-que-resolve-o-que.

Obs: Vale a pena entender o que é um Anti-pattern tambem!

Para exemplificar melhor, vamos descrever um dos padrões mais conhecidos, mais e mais exemplificados e mais mal-entendidos da história do desenvolvimento orientado a objeto: o Singleton!

O Singleton foi originalmente criado pelo renomado grupo Gang Of Four [GoF], formado por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.  Sua definição é:

Garantir que uma classe tenha somente uma instância e fornecer um ponto global de acesso para a mesma.

Resumidamente, a motivação do Singleton é ter um ponto de acesso a uma intancia que seja unica para todo o sistema. As aplicações para este patterns são inúmeras: configuração, tratamento de informação compartilhada, parametrização, manter estado de um objeto, manter instancias de outros objetos que sejam statefull, etc. O qua vai guiar como contruir este objeto é a sua necessidade.

ATENÇÃO: Os códigos utilizados nestes exemplos são meramente ilustrativos.

Vamos ao exemplo mais conhecido de todos:

public class Singleton {

    private static Singleton instance = null;

    private Singleton() {
    }

    public Singleton getInstance(){
        if(instance == null)
            instance = new Singleton();
        return instance;
    }

}

Este sem dúvidas é o código mais conhecido como Singleton. Mas ai começam os problemas…

Se eu tiver em um sistema muito concorrido, pode acontecer de duas instancias serem criadas ao mesmo tempo. Se isso for realmente um problema, refatorando o código poderemos ter algo como:

public class Singleton {

	private static Singleton instance = null;

	private Singleton() {
	}

	public synchronized Singleton getInstance(){
		if(instance == null)
			instance = new Singleton();
		return instance;
	}

}

Sincronizando o método, podemos garantir que apenas uma chamada será processada a cada momento. Mas isso torna o código muito ruim, já que até mesmo depois da criação, todas as chamadas deverão ser sincronizadas e, conforme dito no problema 1, a sua concorrência é grande, o que implica em muitos acessos e uma baixa performance desse método.

Se isso for realmente um problema, para solucionar podemos fazer coisas do tipo:

public class Singleton {

    private static Singleton instance = null;

    private Singleton() {
    }

    public Singleton getInstance(){
        if(instance == null)
            synchronized (Singleton.class) {
                instance = new Singleton();
            }
        return instance;
    }

}

Beleza! com isso conseguimos garantir concorrência e performance, correto? Não, não não… sendo bem purista, ainda há uma possibilidade de haver uma concorrencia na linha 09 do último exemplo. Sim, é possível sim (Calma, são apenas exemplos, rs)! Se isso for um problema, refatorando um pouco mais, podemos ter um código assim:

public class Singleton {

    private static Singleton instance = null;

    private Singleton() {
    }

    public Singleton getInstance(){
        synchronized (Singleton.class) {
            if(instance == null)
                synchronized (Singleton.class) {
                    instance = new Singleton();
                }
        }
        return instance;
    }

}

Pronto! Temos um singleton!!!

Mas ainda temos um probleminha… E se o sistema tiver rolando em Cluster?! Se vc tiver mais de uma JVM, vão existir mais e uma instância do seu singleton, o que deixa de ser singleton!

Bem, perceberam que a ligação entre problema e solução não diz respeito a como codificar. Eu tenho vários exemplos de Singleton acima e até o momento eu não resolvi o meu problema, que é ter uma instância, que suporte concorrência, com performance e em um ambiente distribuido. E eu poderia fazer milhões de implementações diferentes para conseguir chegar ao meu objetivo!

Mas e se eu não me importasse de ter mais de uma instancia no Cluster? E se a minha concorrência fosse muito pequena a ponto de não atrapalhar a minha performance? Isso cabe a você!!! Como eu disse, conhecer o problema e dar a melhor solução possivel!

Existem todos os tipos de pessoas! Existem aqueles que pensam em uma solução, implementam um ou mais padrões sem ao menos conhecer o que está fazendo; como tambem existem aqueles que implementam vários padrões de projeto para um simples Hello World e mesmo assim, a implementação está errada!

Só para termos ideia, vou colocar mais um exemplo de Singleton. Neste eu utilizo o contexto de uma aplicação Web para individualizar a minha instancia.

public class Singleton {

    private static final String KEY = "singleton";

    private Singleton() {
    }

    public Singleton getInstance(ServletContext context){
        Object obj = null;
        obj = context.getAttribute(KEY);
        if(obj == null){
            synchronized (Singleton.class) {
                Singleton singleton = new Singleton();
                context.setAttribute(KEY, singleton);
                return singleton;
            }
        }
        return Singleton.class.cast(obj);
    }

}

Portanto, entender o seu problema, saber qual padrão de projeto aplicar e nomea-lo corretamente é o divisor de aguas.

Até!

Comente e Recomende!

Muitas vezes, por mais que um ‘analista’ entenda 100% do que o cliente solicitou, ele não sabe o que o software tem que fazer quando for dado por completo. Nem o cliente saberá isso em um Brainstorm, ainda mais se vc colocar aquela bendita fase de levantamento no seu cornograma cronograma.

Dividir o produto em UserStories é dar certeza ao cliente e ao desenvolvedor que, apenas aquele pequeno escopo está sendo desenvolvido neste momento (iteração). Ele não precisa se preocupar no momento que lá na frente o produto tem que se comunicar com 50 pontos diferentes. Isso não está no mini-escopo da UserStory a qual o desenvolvedor está focado!

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

Para quem não sabe, eu trabalho no Instituto Nacional do Cancer, com uma equipe de 12 pessoas que desenvolve Java (Web e Mobile) para alguns clientes/institutos satélites do governo. Porem, quando eu cheguei aqui, minha tarefa era “organizar a casa para que os sistemas que estavam em fase final de levantamento tivessem uma melhor performance de entrega”.

Pois bem, fiz a minha parte! Os softwares estão sendo entregues quase como eles descreveram, mesmo com todos os problemas encontrados no meio do caminho! Digo isso porque não sei se enquanto eu escrevi esse post, as novas funcionalidades foram aceitas. Mas ainda me sinto muito insatisfeito com o meu próprio serviço, conforme enumero abaixo:

1. Não há testes por parte da equipe, nem falo de unitários ou integrados. Não há teste automatizado de maneira alguma!;
2. Não há a presença do cliente. Estamos desenvolvendo no escuro, levando em consideração o que o gerente do projeto acha, o que não será (quse com certeza) o que o cliente final deseja;
3. Não há uma definição fechada do que fazer e como fazer. Até mesmo coisas básicas como layout são alterados dias antes da entrega final de um módulo, mesmo sem o concentimento do cliente;
4. Não há gerencia de configuração alguma. Os ambientes de desenvolvimento, homologação e produção são diferentes a ponto de serem utilizadas versões de softwares e bibliotecas comuns diferentes entre esses ambientes;
5. Há sempre o “faz como esse aqui”. Sistemas arcaicos com soluções precárias como exemplo… nesse eu nem preciso me aprofundar muito!
6. Minha-Própria-Metodologia-Ágil não funciona se todos não tiverem completa noção de como funciona. Para qualquer metodologia funcionar, tudo deve estar entendido e todos devem estar de acordo.

Para se ter noção melhor sobre o que eu passo, na proxima terça feira (03/03/2009) deveriamos fazer um deploy contendo 80% do projeto para o cliente. Mas quem vai testar é o gerente do projeto, já que o cliente só vai ver quando o produto estiver 100% pronto. Mas amanhã teremos uma reunião para definir um escopo de versionamento de informações, que é vital para um processo de certificação (escopo do sistema). MAs calmae, amanhã para entregar numa terça?! Sugeri então envolver o cliente, mesmo que por audio conferência, para ter uma solução aprovada por ele, porque a alteração iria ser muito grande. Resposta: Vamos definir entre nós, o cliente será avisado sobre a nossa decisão!!

Um outro exemplo aqui tambem: o sistema ainda não tem usuário final e está em fase de homologação?!? Como assim?!? Quem definiu isso?!?

Enfim, estou muito insatisfeito e tenho plena noção de que não conseguirei alterar isso a curto prazo, ou seja, até a entrega desses produtos aos seus clientes com a etiqueta “SURPRESA!” Gosto muito do local, da empresa, da causa (principalmente) e das pessoas. Mas as metodologias e os modelos estão me esgotando!

Mas a minha saga em busca do projeto-agil-piloto-que-transformará-toda-a-empresa continua!

“Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças” – Charles Darwin

Até!