Contexto

A arquitetura em questão utiliza injeção de dependência com base em interfaces, ou seja, todas as dependências das minhas classes são sempre pra interfaces (contratos) e nunca para classes concretas (implementação) exatamente como manda o figurino.

Meu domínio é o padrão: carrinho de compras com Pedido e seus itens. Uma classe é responsável por efetuar o processamento do pedido (GeradorPedido). Ela executa todos os procedimentos necessários para que um pedido seja gerado de maneira correta, dentre eles aplicar um determinado fator de ajuste de preços dos itens acordo com a loja onde o pedido foi vendido. Este fator de ajuste é determinado pela classe Precificador e deve ser desconhecido para o restante dos outros objetos a fim de não violar o SRP.

O diagrama abaixo representa as classes envolvidas e suas dependências:

Como aplicar este fator ao preço do item não é responsabilidade do GeradorPedido, sempre que uma instância de GeradorPedido é criada, injeto via construtor uma nova instância de Precificador pra ser usado quando necessário. Neste caso, temos uma dependência direta de GeradorPedido para IPrecificador que é resolvida em tempo de execução.

Tudo estava sendo resolvido utilizando Ninject:

MyModule.cs

public class MyModule : NinjectModule
{
    public override void Load()
    {
        Bind<IPrecificador>().To<Precificador>();
        Bind<IGeradorPedido>().To<GeradorPedido>();
    }
}

UnitTest1.cs

[TestMethod]
public void consegue_resolver_GeradorPedido()
{
    MyModule module = new MyModule();
    StandardKernel kernel = new StandardKernel(module);
    var geradorPedido = kernel.Get();

    Assert.IsNotNull(geradorPedido);
}

Precificador.cs

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public Precificador()
    {
        _fatorAjuste = 10m;
    }

    public decimal CalcularPreco(ItemPedido item)
    {
        return item.Preco * _fatorAjuste;
    }
}

GeradorPedido.cs

class GeradorPedido : IGeradorPedido
{
    private IPrecificador _precificador;

    public GeradorPedido(IPrecificador precificador)
    {
        _precificador = precificador;
    }

    public string Processar(Pedido novoPedido)
    {
        decimal total = 0;

        foreach (var item in novoPedido.Itens)
        {
            total += _precificador.CalcularPreco(item);
        }

        //Faz mais algumas operações com pedido

        //Número do pedido
        return "ABC123";
    }
}

Até aqui, tudo OK, certo? Ai entra um novo requisito e com ele aparece o problema…

Novo Requisito

Alguém decidiu que o fator dos preços deveria variar de acordo com a loja em que o pedido estava sendo feito. Se isso é uma regra de preço, a qual classe pertence? Precificador!

Quais opções temos pra implementar isso com o mínimo de impacto possível no sistema (já que a interface IPrecificador já estava sendo usada) e de maneira que a coesão e desacoplamento seja mantido?

Opção 1 – Adicionar um paramêtro no método CalcularPreco

A primeira opção que me veio a cabeça foi adicionar o paramêtro com a loja diretamente no método CalcularPreco da interface IPrecificador.

IPrecificador.cs

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public decimal CalcularPreco(ItemPedido item, Loja vendaEfetuadaEm)
    {
        if (vendaEfetuadaEm == Lojas.LojaUm)
            _fatorAjuste = 10m;
        else if (vendaEfetuadaEm == Lojas.LojaDois)
            _fatorAjuste = 15.4m;
        else
            _fatorAjuste = 0.9m;

        return item.Preco * _fatorAjuste;
    }
}

Parecia uma boa saída, mas depois de pensar alguns minutos encontrei dois side-effects graves que me fizeram mudar de idéia:

1. O novo paramêtro, Loja, passaria também a virar uma dependência direta pra todos que consumissem a interface IPrecificador já que estes [consumidores] seriam responsáveis por repassar a loja para poder realizar a chamada a CalcularPreco. Com isso estariamos violando o SRP adicionando um motivo a mais pra classe GeradorPedido e outras mudarem.
2. Diversos testes seriam quebrados pela adição do novo paramêtro, indicando que talvez não fosse a melhor alternativa já que essa alteração deveria afetar apenas uma classe

Opção 2 – Adicionar este paramêtro ao construtor da classe Precificador e utilizar uma Factory

Já que esta alteração diz respeito apenas a responsabilidade da classe Precificador, que tal adicionar este paramêtro ao construtor da classe? Ótima idéia, não?

De fato foi a solução que fez mais sentido já que necessariamente para chegar ao fator de preço a ser aplicado a classe precisa saber com qual loja estamos lidando. Para implementar, bastaria fornecer a loja via construtor e armazenar o valor em um membro privado da classe pra uso posterior. Dessa forma, todos os consumidores dessa classe iriam receber uma instância de IPrecificador já configurada e pronta pra uso sem a necessidade de se preocupar em fornecer a loja.

Nosso novo Precificador.cs ficaria assim:

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public Precificador(Loja vendaEfetuadaEm)
    {
        if (vendaEfetuadaEm == Lojas.LojaUm)
            _fatorAjuste = 10m;
        else if (vendaEfetuadaEm == Lojas.LojaDois)
            _fatorAjuste = 15.4m;
        else
            _fatorAjuste = 0.9m;
    }

    public decimal CalcularPreco(ItemPedido item)
    {
        return item.Preco * _fatorAjuste;
    }
}

No entanto, na hora que fui implementar esta solução esbarrei no meu container de DI, até então o Ninject, que resolvia a dependência de IPrecificador pra mim automaticamente sempre que necessário. Contudo, pra esta implementação eu precisaria fornecer um valor (a Loja) que só podia ser obtido em runtime na hora de construir a instância de IPrecificador.

Então a solução seria utilizar uma Factory!

GeradorPedidoFactory.cs

class GeradorPedidoFactory
{
    public static IGeradorPedido Criar(Loja vendaEfetuadaEm)
    {
        IPrecificador precificador = new Precificador(vendaEfetuadaEm);
        return new GeradorPedido(precificador);
    }
}

Mas trinta segundos depois descartei essa idéia porque IPrecificador estava sendo usado por outras classes além de GeradorPedido então eu teria que criar uma factory pra cada uma das classes que fosse consumidora de IPrecificador. Também dessa forma eu estaria anulando meu Container de DI espalhando a criação de tipos concretos por diversas factories ao invés de centralizar em apenas um ponto.

Opção 3 – Manter o construtor e utilizar uma Abstract Factory pra criar IPrecificador

A terceira e ultima opção antes da solução final foi utilizar uma Abstract Factory, que seria injetada via DI em todo mundo que precisasse de IPrecificador eliminando a necessidade de uma factory pra cada construtor e mantendo a responsabilidade no lugar adequado. Algo assim:

PrecificadorFactory.cs

class PrecificadorFactory : IPrecificadorFactory
{
    public IPrecificador Criar(Loja vendaEfetuadaEm)
    {
        return new Precificador(vendaEfetuadaEm);
    }
}

MyModule.cs

public class MyModule : NinjectModule
{
    public override void Load()
    {
        Bind<IPrecificadorFactory>().To<PrecificadorFactory>();
        Bind<IGeradorPedido>().To<GeradorPedido>();
    }
}

GeradorPedido.cs

class GeradorPedido : IGeradorPedido
{
    private IPrecificadorFactory _precificadorFactory;

    public GeradorPedido(IPrecificadorFactory precificadorFactory)
    {
        _precificadorFactory = precificadorFactory;
    }

    public string Processar(Pedido novoPedido, Loja vendaEfetuadaEm)
    {
        IPrecificador precificador = _precificadorFactory.Criar(vendaEfetuadaEm);
        decimal total = 0;

        foreach (var item in novoPedido.Itens)
        {
            total += precificador.CalcularPreco(item);
        }

        //Faz mais algumas operações com pedido

        //Número do pedido
        return "ABC123";
    }
}

Contudo, na hora que implementei pra ver como ficaria, percebi que tinha o mesmo problema da primeira solução: todo mundo que precisasse consumir IPrecificador teria que receber o paramêtro informando a Loja onde a venda foi efetuada para repassar para a abstract factory de IPrecificador a fim de criar uma instância concreta da classe. A dependência tinha voltado, apesar de a responsabilidade estar um pouco melhor distribuida.

A Solução Final

Quando eu já estava quase desistindo de procurar outra alternativa (mais uma) o @pedroreys deu uma idéia excelente: fornecer previamente ao container de DI a instância de IPrecificador que deveria ser usada quando ela fosse necessária.

Na hora fui atrás de como fazer isso com o Ninject que, era meu container até então. Infelizmente ele não implementa essa funcionalidade especifíca. Pelo menos não da maneira que eu gostaria [1].

Foi ai que decidi mudar para o StructureMap, container utilizado no exemplo do @pedroreys. O StructureMap, apesar de ter sido um dos primeiros containers de DI/IoC lançados (e de ser um pouco verboso demais pro meu gosto), se mantém atualizado e com uma excelente interface fluente exatamente como o Ninject.

A troca foi simples já que eu utilizo um Wrapper (omitido por breviedade) pro Ninject e a aplicação não tem contato com o container em si. O resultado acabou sendo um Mix de todas as soluções:

PrecificadorFactory.cs

class PrecificadorFactory
{
    public static IPrecificador Criar(Loja vendaEfetuadaEm)
    {
        return new Precificador(vendaEfetuadaEm);
    }
}

UnitTest1.cs

[TestMethod]
public void consegue_resolver_GeradorPedido()
{
    Loja vendaEfetuadaEm = RecuperarLojaOndeVendaFoiEfetuada();

    IPrecificador precificador = PrecificadorFactory.Criar(vendaEfetuadaEm);

    Container container = new Container();

    IGeradorPedido geradorPedido = container.With<IPrecificador>(precificador).GetInstance<IGeradorPedido>();

    Assert.IsNotNull(geradorPedido);
}

Dessa forma consigo:

1. Criar a instância de IPrecificador separadamente
2. Dizer ao container que quero que esta instância especifica seja usada somente nesta resolução de IGeradorPedido
3. Manter cada classe com sua responsabilidade

Any thoughts o this?

[1] – O Ninject, na última versão (2.0), implementa o método Rebind() que permite trocar o bind de uma interface em runtime. No entanto, esta troca é permanente e afeta todos os consumidores do container (Singleton, no meu caso) e no meu contexto, não faz muito sentido.

Os vídeos da apresentação do Giovanni sobre DDD e do debate posterior também já estão disponíveis para quem não pode ir ou tem interesse no assunto assim como os slides:

Apresentação

Debate

Slides

Olha como melhoramos! Em comparação com o material da minha apresentação, a gravação do áudio e vídeo já estão muito melhores.

Obrigado e parabéns novamente ao pessoal da UNIP que está apoiando a gente.

Fui pesquisar, mas não encontrei nenhuma ferramenta gratuita web que pudessemos usar. Foi ai que surgiu o .NET Scrum. A idéia não é construir nada pra competir com o que existe por ai, mas utilizar da idéia pra ter um laboratório e construir um projeto onde possamos aplicar o que há de mais novo em tecnologia além de boas práticas de engenharia e condução de projetos.

Portanto, quem der uma olhada no projeto e quiser contribuir ou apenas acompanhar vai encontrar um ASP.NET MVC, jQuery, NHibernate usando interfaces fluentes, DDD, TDD, Spring.NET e outros frameworks e design patterns importantes para a construção de uma boa solução em .NET.

Se deixarmos de lado a parte tecnológica também é possível aprender um bocado trabalhando na organização de um projeto open source. Projetos de código aberto e mantidos pela comunidade são o maior caso de sucesso de times distribuidos trabalhando juntos a fim de atingir um objetivo. Se já é difícil obter sucesso em um projeto com o time no mesmo lugar, imagine trabalhar com pessoas que você nunca viu na vida e com comunicação relativamente limitada? Um grande desafio!

O Maurício Aniche que participa do DotNetArchitects já se juntou ao projeto pra me ajudar. Já existem alguns códigos publicados no codeplex e uma documentação miníma também. Quem quiser ajudar é mais do que bem vindo!

Este é um dos livros que recomendo fortemente a leitura e que está na minha seção de indicados. Acredito que todo bom desenvolvedor deve dar uma boa lida, pois os benefícios oferecidos pela técnica são inúmeros.

Embora eu prefira livros impressos e tenha este é uma ótima maneira de economizar e ter o livro disponível sempre que precisar para referências.

Fica ai a dica!

O local será o mesmo das outras vezes, na UNIP Jaguaré. Nesta semana o Giovanni irá falar um pouco a respeito de Domain Driven Design.

A participação é aberta e muito bem vinda. Quem ainda não mandou seus dados pode fazer pelo blog do Giovanni ou pelo grupo do Google onde também está disponível a pauta para próxima reunião.

Na última reunião falei sobre Scrum e o vídeo da apresentação está disponível aqui no blog e no site do grupo.

A idéia de banco de dados orientado a objetos sempre me agradou e acho uma pena não ter chegado ao mainstream. No entanto o conceito de armazenar o grafo todo de objetos é muito interessante em algumas situações. Vou usar um exemplo que talvez não seja o melhor, mas deve passar a idéia.

Imagine um cadastro de cliente com diversas entidades relacionadas: diversos endereços, vários telefones para contato, dependentes, etc.

Modelo de Classes

Normalmente criaríamos uma tabela para cada uma das entidades e essas tabelas teriam uma referência (FK) para a tabela principal de clientes:

Modelo de Dados normalizado

Se considerássemos que um endereço ou automóvel pudesse pertencer a mais de um cliente a coisa ficaria ainda mais complicada e teríamos que criar tabelas de relacionamento N:M.

Para que o exemplo seja útil, vamos considerar que nesse sistema não fosse possível efetuar pesquisas utilizando como filtro nenhuma dessas entidades (em um sistema real é óbvio que requisito é um absurdo) e só seria disponibilizada uma funcionalidade de busca por meio de código (id). Mesmo com esse requisito, como pensamos sempre em de forma relacional o caminho natural seria criar o modelo de dados acima e armazenar tudo bastante normalizado.

No entanto existe outra opção que em determinados casos é muito interessante. Guardar o objeto inteiro no banco.

Em .NET, por exemplo, bastaria criar um modelo simples de dados contendo o idCliente e um campo que armazene binário (varbinary em SQL), serializar o objeto e pronto.

Modelo de dados mais simples

public Cliente Consultar(int codigoCliente)
{
//Recupera do DB
byte[] clienteSerializado = DaoCliente.ConsultarPorCodigo(codigoCliente);
//Devolve o objeto deserializado
return this.DeserializarObjeto<Cliente>(clienteSerializado);
}

public void Salvar(Cliente novoCliente)
{
//Serializa o objeto
byte[] clienteSerializado = this.SerializarObjeto<Cliente>(novoCliente);
//Guarda o cliente no DB
DaoCliente.Inserir(novoCliente.Codigo, clienteSerializado);
}

private byte[] SerializarObjeto<T>(T objeto)
{
MemoryStream ms = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(ms, objeto);
byte[] objetoSerializado = ms.ToArray();
ms.Close();
return objetoSerializado;
}

private T DeserializarObjeto<T>(byte[] objetoSerializado)
{
MemoryStream ms = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
ms.Write(objetoSerializado, 0, objetoSerializado.Length);
ms.Position = 0;
return (T)formatter.Deserialize(ms);
}

Dessa maneira, sempre que precisarmos, já iremos ter o objeto completo e não seria necessário executar diversas instruções SQL ou stored procedures e muitas chamadas ao banco. Iriamos apenas executar uma chamada que nos retornaria o objeto completo e pronto para uso.

Essa é uma solução diferente e que pode ser útil em alguns cenários, principalmente se você não utiliza nenhum framework ORM. Contudo, é importante verificar todos os requisitos com bastante cuidado, com essa solução corremos o risco de ficar com dados desatualizados e perdemos a possibilidade de efetuar buscas por campos que estejam dentro dos objetos armazenados.

Acho muito legal encontrarmos formas diferentes de fazer as mesmas coisas que estamos habituados. É uma maneira muito eficiente de aprendizado e conhecimento das nossas ferramentas.

O que você acha?

Editado: sem saber, acabei descrevendo o pattern Serialized Lob já catalogo pelo Fowler em seu livro PoEAA. O Bruno achou e comentou o post colocando este link. Valeu!

Depois do oba-oba que a comunidade fez contra o Entity Framework que acabou saindo meio mal acabado e ainda totalmente focado em banco de dados sem suporte a PI para POCOs no SP1 a Microsoft finalmente deu uma dentro.

Eles convidaram Eric Evans (criador do domain-driven design), Martin Fowler (não preciso dizer quem é, né?), Jimmy Nilsson (praticante de DDD com .NET que escreveu um ótimo livro), Stephen Forte e Pavel Hruby para formar um conselho com o objetivo de palpitar a respeito de como o Entity Framework deveria ser remodelado.

Com esse pessoal todo envolvido e mais algumas coisas que o pessoal anda soltando no blog do EF, boto fé que vem coisa boa ai pela frente!

A “notícia” pode ser vista com mais detalhes neste link.

Applying Domain-Driven Design and Patterns

Terminei essa semana de ler o livro do Jimmy Nilson “Applying Domain-Driven Design and Patterns: with examples in C# and .NET” e vou compartilhar minhas impressões.

É um livro com 11 capítulos, 2 apendíces e aproximadamente 500 páginas. Paguei R$100,00 na Livraria Cultura e chegou em menos da metade das 8 semanas prometidas no site.

Geralmente livros técnicos depois de algumas página se tornam cansativos de ler. Não li nenhum outro livro deste autor anteriormente, mas o cara escreve de uma forma muito gostosa e tranquila de se ler. Nos primeiros dias eu não conseguia fechar o livro. Tive que me segurar pra não passar a madrugada lendo.

Quando comprei o livro imaginei que fosse unicamente a respeito de DDD, mas na prática são poucos os capítulos referentes a esse assunto.

O primeiro capítulo é bastante interessante (principalmente pra quem não está acostumado com agilidade, DDD e Testes) porque ele conceitua esses pontos de uma forma que é impossível não ter vontade de aplicar e ler mais sobre.

A partir dai e durante todo o livro ele apresenta diversos design patterns e como aplicá-los em situações práticas. Existe também um capítulo inteiro sobre TDD que passa por todos os aspectos desde o ciclo de desenvolvimento com TDD, mocks e stubs, e até técnicas de refatoração.

A partir do quarto capítulo que ele comça a falar propriamente dos novos aspectos da modelagem orientada ao domínio e da nova proposta de arquitetura. Sempre com muitos exemplos de código e modelos.

Antes de ler o livro eu havia lido muito a respeito de DDD no GUJ, no resumo do livro do Evans e mais da metade do livro que deu origem ao resumo. Exatamente nesta ordem. Então já estava bem familiarizado com os novos conceitos e já havia aplicado bastante.

Acho que por conta disso, me decepcionei um pouquinho, pois o Jimmy Nilson falou quase nada a respeito de Services e de interações mais complexas entre objetos. Outro ponto que me deixou bastante frustrado foi o fato dos exemplos dos repositórios serem implementados apenas com ORM (NHibernate no caso deste livro). Em Java ORM é uma realidade. Em .NET a coisa ainda está começando a andar com o LINQ, EF e o próprio NHibernate, mas a maioria das pessoas ainda implementa acesso a dados na mão. No fundo, acho que o fato de implementar repositório de forma elegante apenas com ORM é um problema do padrão e não do livro (esse é assunto pra um outro post que vai render pedras). Eu particularmente gosto muito de implementar na mão (mais pedras!).

Outro ponto que ficou por último, mas sem menos importância é UI. Ele fala de UI com MVC e MVP inclusive a respeito de como testar a UI. No entanto achei que os exemplos nesse caso não ficaram legais principalmente pelo fato de durante todo o livro o conceito de web ser enfatizado e no caso da UI os testes serem escritos com exemplos em Windows Forms.

Já ao final do livro alguns colegas dele falam a respeito de outros padrões e frameworks tais como: PI utilizando POCO/POJO, SOA, AOP, DI, IoC, NHibernate e SPRING. Inclusive este livro serve como um bom início para o aprendizado desses frameworks, pois os exemplos ilustram cenários bastante reais e práticos.

E por último mais alguns colegas explicam outras abordagens de design de aplicação orientada a domínio.

Se você ficou empolgado por imaginar que fosse encontrar bons exemplos de como testar sua UI nesse livro, acho que essa não é a melhor literatura. Mas para todo o restante dos assuntos é um livro altamente recomendado e que me proporcionou muito aprendizado durante a leitura.

No entanto, poucas são as pessoas que realmente se preocupam se seu modelo está com o mínimo possível de qualidade (não é?), vista a quantidade de modelos orientados a banco de dados que vemos por ai. Menos pessoas ainda, são as que procuram entender e se aproveitar das sutilezas existentes nos objetos para tornar o modelo mais claro e ter como boa conseqüência a comunicação de suas intenções facilitada.

Bons designers utilizam-se da linguagem pra facilitar seu trabalho.

O ponto que me motivou a escrever sobre isso é o motivador para utilização de propriedades e métodos. Desde a teoria mais básica de orientação a objetos aprendemos que objetos são classes (entidades) que possuem estado (propriedades) e comportamento (métodos) próprio.

Em .NET possuímos propriedades nativamente. Em java obtemos propriedades através de métodos get() e set(), por exemplo. Diretamente ou não, todas as linguagens orientadas a objetos fornecem mecanismos para utilização de propriedades. Mas quando devemos utilizar propriedades ao invés de métodos?

Conforme a própria teoria, propriedades devem refletir o estado de um objeto, ou seja, as características que o definem naquele exato momento de sua vida. Como exemplo simples teríamos dentro de um objeto do tipo Cliente as propriedades: Nome, Telefone, Idade, Sexo, etc. No entanto, a partir do momento em que para responder a uma pergunta sobre seu estado o objeto precise efetuar algum tipo de processamento deveremos transformar a então propriedade em um método, pois propriedades devem ser utilizadas para descrever estado que seja sabido “de bate pronto” pelo objeto em questão. Qualquer outro tipo de resposta a perguntas feitas para o objeto deve ser respondida através de métodos.

Um exemplo um pouco mais concreto: vamos imaginar que estamos desenvolvendo um sistema de controle de usuários e que no momento de uma exclusão de usuário precisamos saber se ele possui ou não emails.

Podemos modelar desta maneira:

Utilizando propriedades

Claro que existem exceções, mas normalmente um usuário não sabe se possui emails (a não ser que fique de 5 em 5 minutos apertando o botão send/receive do outlook! ) e no caso desta pergunta teria que sair de onde está, ir até sua mesa, abrir seu programa de email e verificar se possui ou não algum email. O administrador poderia checar, mas deveria também executar uma série de operações até descobrir se o usuário possui ou não emails. Sendo assim, acredito que essa operação deveria ser comunicada de forma explicita por meio de um método para que quem estivesse utilizando essa API soubesse que uma operação (processamento) irá ocorrer para checar se existem ou não emails.

Outro motivo para utilização de métodos nesses casos é a possível necessidade de passagens de parâmetros para essas verificações. Ainda no nosso cenário de controle de usuários, vamos assumir que um novo requisito deve ser implementado: somente os usuários que não receberam emails na última hora podem ser removidos. Se utilizarmos propriedades como no exemplo acima como iríamos fazer? Criar outra propriedade chamada “RecebeuEmailNaUltimaHora”? Ou poderíamos modelar dessa forma:

Utilizando métodos

Desta maneira, acredito que o mundo real seja mais bem representado e o utilizador da API irá utilizar os métodos com mais cuidado, pois o modelo comunica que para fazer essa verificação é necessário processamento (que pode ou não ser pesado). Outro ponto a favor é que podemos ter (quanto menos melhor) diversos métodos para execução de operações, mas caso esse tipo de checagem deva ser feito de diversas maneiras não podemos sair criando uma propriedade para cada um dos cenários senão corremos um sério risco de desconfigurar a identidade do objeto por ter propriedades demais.

Como tudo em OO, não devemos ter isso como uma regra, mas sim verificar o que é melhor para cada cenário. Acredito que mais do que a sugestão apresentada nesse post, o mais importante é a mensagem de que devemos modelar com cuidado procurando abstrair nosso domínio da maneira mais fiel possível e comunicando o máximo através das ferramentas que a OO nos oferece.