Arquivo da tag: Practices

Event Driven Architecture (Parte 2)

Olá pessoal!

No post anterior vimos alguns conceitos de Event-Driven Architecture e como seria sua arquitetura de referência. Neste veremos as possíveis realizações de tal arquitetura de referência e também iremos conferir alguns princípios que devem ser levados em consideração ao se fazer o design deste tipo de arquitetura.

Vamos começar então pelas possíveis utilizações de uma Event-Driven Architecture. No livro Event Processing: Designing IT Systems for Agile Companies são relacionadas três principais cenários: Disseminação de Informação, Conhecimento de Situação e Integração de Aplicações. Cada possível utilização demanda uma forma distinta de implementação da arquitetura de referência vista. Vejamos cada uma delas a seguir.

Continue lendo

Event Driven Architecture (Parte 1)

Olá pessoal!

Neste post veremos um conteúdo bastante interessante. Se você busca um estilo arquitetural que proporcione benefícios para sua organização como execução de processos de negócio em menor tempo, agilidade em resposta às mudanças e disponibilidade de informação para tomada de decisão, então você deveria dar uma olhada em “Event Driven Architecture”.

Neste artigo entenderemos o conceito de eventos e eventos de negócios, veremos porque uma arquitetura orientada a eventos é importante e como tal arquitetura se realiza de forma lógica. Já na parte 2 desta série, veremos como a arquitetura lógica vista aqui se realiza fisicamente (quais são os produtos envolvidos) e alguns princípios que devem ser considerados ao se estabelecer tal arquitetura.

Continue lendo

What Makes a “Good” Architecture?

Olá pessoal!

Neste post vou falar sobre mais um tópico bastante interessante do livro Software Architecture in Practice – Second Edition, já citado em um post anterior. Desta vez o tema é “o que faz uma boa arquitetura”. Segundo o livro, diferentes arquitetos em diferentes organizações projetam diferentes arquiteturas, de forma que seja complicado definir qual é a mais correta. A ideia geral do tópico é que a arquitetura mais apropriada é aquela que melhor atende aos propósitos definidos para o sistema, sendo que não há uma fórmula única. Diferentes tipos de arquiteturas atendem a diferentes tipos de demandas. Uma arquitetura distribuída, baseada em estrutura client-server pode ser adequada para uma companhia de grande porte do setor financeiro, porém, a mesma solução pode ser completamente inapropriada para uma aplicação voltada à aviação, ou a um compilador, ou ainda a um jogo de vídeo game. E como não há uma fórmula, o tópico estabelece algumas “regras de ouro”, que podem ser usadas em todos os tipos de demandas. As recomendações são classificadas em relacionadas ao processo e ao produto (ou estrutural). Vejamos a seguir:

Software Architecture in Practice - Second EditionRecomendações relacionadas ao processo

  • A arquitetura deve ser produto de apenas um arquiteto ou de um grupo pequeno, com um líder identificado. Acredito que esta dica esteja relacionada ao anti-pattern Design by Committee, em que a opinião de muitas pessoas é levada em consideração, atendendo seus egos ao invés das reais necessidades, resultando em uma arquitetura pouco eficiente.
  • O arquiteto ou time de arquitetos deve ter uma lista de requisitos funcionais, bem como uma lista priorizada do que é definido como atributos de qualidade (devo falar mais sobre este assunto em um próximo post), que são, por exemplo, escalabilidade, performance, segurança, facilidade de manutenção, etc.
  • Uma arquitetura deve ser bem documentada, de forma que ao menos uma visão estática e uma dinâmica sejam produzidas. Uma visão estática pode ser um diagrama de componentes ou de implantação da UML. Já a dinâmica pode ser obtida com os diagramas de sequência ou comunicação, por exemplo, também da UML.
  • Uma vez documentada, a arquitetura deve ser bem conhecida por todos os stakeholders (clientes / áreas de negócios solicitantes, analistas, desenvolvedores, líderes de projetos, gerentes de projetos, etc.), que por sua vez devem se envolver ativamente na sua revisão.
  • Uma arquitetura deve ser analisada através da medição de atributos quantitativos (por exemplo, throughput máximo) e avaliada formalmente quanto aos atributos de qualidade que deve atender, antes que seja tarde para que alterações sejam feitas.
  • Uma arquitetura deve ter como resultado um sistema “esqueleto” (estrutura inicial em camadas, serviços, projetos, soluções, etc.) em que caminhos de comunicação sejam testados com funcionalidades mínimas. Uma vez estabelecida, esta estrutura pode ser usada para o crescimento incremental do sistema.
  • Uma arquitetura também deve ter como resultado documentações de soluções para áreas de contenção específicas, como por exemplo, utilização de rede, processador, etc.

Recomendações relacionadas ao produto / estrutura

  • Uma arquitetura deve ter como característica a definição de módulos cujas responsabilidades funcionais devem ser alocadas de acordo com os conceitos information hiding e separation of concerns.
  • Cada módulo deve ter interfaces bem definidas, que encapsulem ou escondam aspectos sujeitos a mudanças. Estas interfaces devem permitir que times de desenvolvimento trabalhem de forma independente entre si (achei este item redundante com relação ao anterior, mas deixei para ficar aderente ao livro).
  • Arquitetos devem se preocupar e devem buscar o atendimento de atributos de qualidade. É comum que arquitetos se preocupem apenas com os requisitos funcionais, deixando questões importantes aparecerem apenas quando o sistema entra em produção. Existem táticas específicas para atender requisitos de qualidade. Também falarei sobre este assunto em detalhes em próximos posts.
  • Uma arquitetura nunca deve depender de versões específicas de produtos comerciais. Se a integração com produtos comerciais for necessária, deve-se projetar a arquitetura para que mudanças futuras para um produto diferente ou para uma nova versão sejam feitas de forma trivial e pouco custosa (camadas de indireção podem ser usadas neste sentido).
  • Módulos que consomem dados devem ser separados de módulos que produzem dados, visando prover maior facilidade de manutenção, uma vez que as mudanças normalmente ocorrem ou no lado consumidor ou no lado fornecedor do dado.
  • Para sistemas com processamento paralelo, a arquitetura deve prover processos ou tarefas bem definidas que não necessariamente espelham a decomposição estrutural dos módulos.
  • Ainda com relação a processamento paralelo, cada processo ou tarefa deve ser escrito de forma que a atribuição para um processador específico seja facilmente alterada, preferencialmente em tempo de execução.
  • A arquitetura deve dispor de um número pequeno de padrões de interação. Ou seja, em geral, o sistema deve fazer as mesmas coisas da mesma forma, provendo maior facilidade de entendimento e leitura do código, melhorando e facilitando modificações futuras.

A maioria destas recomendações são seguidas de forma intuitiva, ou mesmo são embasadas por diferentes estudos ou experiências que levam a estas conclusões. É interessante ter esta consolidação de boas práticas para utilizá-las como um guia a ser lembrado em cada novo projeto de arquitetura. Nos próximos posts devo falar mais sobre assuntos específicos tratados de forma incipiente neste. Até lá.

Leitura recomendada: PerfTestGuide, Application Architecture Guide, ebookAS

Olá pessoal!

Por falar em arquitetura, neste post gostaria de registrar três e-books que devem fazer parte da biblioteca digital de todo arquiteto que trabalha com tecnologias Microsoft.   

  • Application Architecture Guide (v.2.0 – 2009): Com o próprio nome já sugere, trata-se de um guia de arquitetura criado pelo grupo Patterns e Practices e disponibilizado gratuitamente pela Microsoft. O e-book cobre três assuntos principais relacionados a arquitetura de software Microsoft e ainda conta com um apêndice. Os três assuntos são:
    • Software Architecture and Design: Resumo de princípios e padrões para fundamentação de uma boa arquitetura. Também provê uma abordagem para criação do seu próprio modelo de arquitetura.
    • Design Fundamentals: Um guia para definição de camadas, componentes e serviços. Também aborda o endereçamento de atributos de qualidade.
    • Application Archetypes: Guias específicos para tipos de arquiteturas específicas, como por exemplo: Web, RIA, Rich Client, Mobile e Services. 
  • Performance Testing Guide for Web Applications (2007): O nome também já diz tudo. Também é um guia criado pelo grupo Patterns e Practices e disponibilizado gratuitamente pela Microsoft. Foi construído com base em experiências práticas aprendidas por diversos profissionais do ramo. O e-book abrange a inclusão do teste de performance em ambientes ágeis e estruturados (p. ex. CMMI), técnicas de teste de performance (p. ex.: teste de carga, teste de stress) e também atividades chave relacionadas (identificação de objetivos, design e execução dos testes, análise e report de resultados). 
  • ebook Arquitetura de Soluções (v.1.0.1 – 2009): Trata-se de uma compilação de diversos assuntos abordados pelo arquiteto de soluções Waldemir Cambiucci, da Microsoft, em seu blog ao longo de dois anos. Dentre os diversos assuntos, constam textos sobre SOA, SaaS, interoperabilidade, modelos de maturidade, recursos da plataforma Microsoft, frameworks de desenvolvimento, domain specific language e diversos outros.

  

Leitura recomendada

Leitura recomendada

Enterprise Library – Overview

Olá pessoal! 

Hoje vou falar um pouco sobre um assunto que me parece estar um pouco fora de moda, a Enterprise Library, também conhecida como EntLib. Digo fora de moda, pois não tenho visto recentemente esse assunto em listas de discussão, artigos e revistas técnicas. Hoje falamos muito sobre tecnologias emergentes como o NHibernate, MVC e suas variantes, DDD, TDD, BDD, AOP, WWF, WCF, WPF, dentre diversas outras, e acabamos por nos esquecer desta que é uma ótima base para construção de sistemas. 

A Enterprise Library consiste em um conjunto de componentes reutilizáveis, desenvolvidos pelo grupo de Patterns e Practices da Microsoft (veja o link no final do artigo), com o objetivo de nos ajudar em questões que nos deparamos em praticamente todas as nossas demandas de desenvolvimento. Ela é composta por blocos de aplicação (normalmente referenciado como application blocks) que tratam de diversos assuntos específicos, sendo eles: cache de dados, tratamento de exceções, segurança, validação de dados, criptografia, acesso a dados, log e injeção de políticas. Veja na figura a seguir como esses blocos se relacionam.      

Application Blocks da Enterprise Library - Clique para ampliar

Imagem retirada do blog do Luciano Condé, arquiteto de soluções Microsoft. Veja o link para o seu artigo no fim deste artigo.

Muito provavelmente você já precisou construir ao menos uma ou mesmo todas as funcionalidades providas pela EntLib ao longo da sua experiência. O objetivo em utilizar esta biblioteca é justamente aproveitarmos códigos já prontos, testados e desenvolvidos sob os melhores conceitos de design. Ou seja, além de embutirmos maior qualidade em nosso software, com a economia do tempo que levaria para construir estas funcionalidades ainda sobra um tempinho para se dedicar ao que realmente importa para o seu cliente: as funcionalidades que atendem ao seu negócio.    

Falando em melhores práticas, é interessante saber que o time que desenvolveu a EntLib levou a sério quatro objetivos na hora de projetar o seu design, os quais são: consistência, extensibilidade, facilidade de uso e integração. Segundo sua documentação, a EntLib foi desenvolvida para cenários de aplicações corporativas com larga distribuição e complexidade. Também teve como base rigorosos requisitos de segurança, confiabilidade e performance. Porém, em minha opinião, isso não significa que ela não possa ser utilizada em aplicações menos complexas ou de menor escala. Me surpreendi com a facilidade de utilização de alguns blocos.    

Desde janeiro de 2006 a EntLib já contou com quatro versões principais, estando no momento da escrita deste artigo em sua versão 5.0, o que deixa evidente a intenção de continuidade e evolução por parte da Microsoft. Isso nos dá uma certa segurança, pois, não é desejável que nossos sistemas dependam de bibliotecas obsoletas. Também é importante destacar que junto com as bibliotecas são providos os seus fontes, de forma que se esta tendência for por água abaixo, ainda nos sobra alguma alternativa.  

Algumas boas notícias. A Enterprise Library pode ser baixada gratuitamente através do site da Microsoft. Encontram-se também disponíveis diversos materiais para estudo que não só são de ótima qualidade como também são muito didáticos. O time caprichou em hands-on labs que podem ser seguidos sem complicações e rapidamente. Para se ter uma idéia, alguns hands-on duram apenas cerca de quinze minutos e dão uma ótima visão do bloco de aplicação coberto. Portanto, não há desculpa para não dar uma estudada!   

Nos próximos artigos falarei um pouco mais sobre cada bloco de aplicação. A seguir seguem alguns links sobre o assunto.