[deprecated]

Olá, como vai você?

Espero que esteja tudo bem! Nesse post vou falar das mudanças previstas para o Oragon Architecture nas próximas semanas. No post Oragon Architecture – A evolução e os novos desafios eu falo da evolução ao longo dos anos e do que pretendemos fazer focando no big picture do projeto. Agora é hora de especificar os detalhes que envolvem a construção do projeto. Enfim, transformar uma ideia em resultado, para isso é necessário planejar. Abaixo vamos abordar a estratégia de migração do Oragon Architecture. Espero que goste!

Eu já planejei essa reestruturação algumas vezes, durante todo o ano de 2013 tentei colocar em prática, mas de fato não tive muito sucesso em definir um target para o projeto. A última, fracassada tentativa, foi no final de ano, com os intervalos e recessos do período. Mas acabei por me envolver em outras atividades, essas com pessoas, e optei por adiar um pouco mais. Fato que o Oragon Architecture se mostrou bem mais eficiente do que eu mesmo sugeriria para a versão atual, mas chegou a hora de pensar no futuro e na evolução da plataforma .Net. Continuar com dependências e códigos muito antigos representa uma incerteza de aceitação para o projeto, mesmo que se consolide cada vez mais em cada cliente que passo e consigo disseminá-lo.

Muita coisa vem evoluindo na plataforma .Net, e de fato estou surpreso com o que o mercado e mesmo o Fowler apelidaram de MicroServices. Fato que me corrói por dentro ver uma um novo business word para as mesmas coisas de sempre. Bom, vou continuar chamando de Segregação de Serviços e Isolamento de Deploy, ou não, MicroServices pode ser o nome. Tanto faz! Mas o mais relevante é que o conceito não é novo, e a abordagem do Spring.Net para abstrações de serviços, sempre impulsionou nessa direção. Já fazem muitos anos que não hospedo serviços WCF no IIS, e acreditem, ainda escuto pessoas achando isso estranho. Conceitos como Host de Processos genéricos, causam frio na espinha das pessoas, o que eu também não entendo. Bom, o Oragon Architecture está aqui para ajuda nessas e diversas outras tarefas chatas do dia-a-dia do desenvolvimento de soluções corporativas. A real intenção do projeto é fornecer uma série de abstrações, para isso usando diversos frameworks de mercado, para oferecer uma experiência de desenvolvimento focada no negócio.

Enfim, sejamos práticos, enquanto a praia de muitos desenvolvedores é entregar soluções, a minha é entregar ferramentas para que suas soluções sejam desenvolvidas de forma mais rápida, mais configurável, e mais flexível, impulsionando e promovendo o refactoring contínuo.

1) Novos assemblies e isolamento de responsabilidades

Quando adicionávamos o Oragon Architecture a qualquer solução dependíamos de dúzias de referências que muitas vezes sequer seriam utilizadas. Agora ficou mais simples, o Oragon Architecture depende apenas do .Net Framework. Mas boa parte das funcionalidades se mantiveram, mas em assemblies isolados. Cada assembly contempla uma integração com um framework, solução ou estratégia. Por exemplo, se você usa aspectos, vai precisar do Spring.Aop, caso contrário não precisará mais, o mesmo acontece com NHibernate, e MongoDB, se seu projeto precisa de um dos dois frameworks, somente o que você precisa será referenciado, no passado o Oragon Architecture continha referência para mais de 20 assemblies de terceiros.

Na prática

Agora temos um pacote base para AOP, ele depende apenas do Spring AOP. Um outro pacote para NHibernate (já atualizado para a versão 4.0 Alpha) e outro para FluentNHibernate. Outro pacote exclusivo para MongoDB, outro para Redis e por aí em diante.

Esse é o novo diagrama de dependências. Na versão 6, tínhamos um único assembly dependendo de toda essa infraestrutura. Agora fica mais fácil escolher o que usar.

2) Target Framework 4.5.1, NuGet e Assemblies de Referência

A intenção é revisitar tudo que muda com o Framework 4.5, implementando as novas features envolvendo performance. TPL e WCF serão assuntos tratados seriamente nessa nova versão. Passaremos a usar e fornecer o Oragon Architecture via NuGet. Esse é um meio de deixar o projeto mais up-to-date possível. Desde já sabemos que alguns pacotes, específicos para a Geração de Código, não estão disponíveis via NuGet, por isso farei a publicação no NuGet eu mesmo, com o sufixo Oragon.

3) Novo Host de Processos

Com OWIN e Katana, os desenvolvedores .Net começam a compreender o funcionamento de um Host de Processos. Embora já acompanhe o Oragon Architecture ha algum tempo, o Host de Processos Oragon, chamado de Oragon Architecture Generic Host vai ser reescrito. Há uma boa probabilidade de continuar usando o TopShelf para a abstração das configurações de integração com o Service Manager do Windows, mas isso é papo para outro post.

4) Comentários, Documentação e Exemplos

É difícil tratar desse assunto com tanta coisa evoluindo, mas vou iniciar uma tarefa extremamente trabalhosa: Criar uma documentação, Step-by-step e adicionar comentários para toda o projeto. Essa é a parte que embora seja a mais chata, sem dúvida é a que dará maior retorno.