Um guia para discutir arquitetura de soluções na plataforma .NET.

Olá pessoal, tudo certo?

No post anterior falamos de organização de componentes e arquitetura de soluções, iniciando uma discussão sobre como nossas aplicações podem ser estruturadas. Em minhas últimas conversas com empresas e arquitetos, observei uma preocupação constante em como posicionar as novas tecnologias e frameworks disponível na plataforma Microsoft em nossos desenhos de arquitetura.

Pensando nisso, a figura a seguir apresenta uma proposta para aplicações em .NET, destacando a camada de apresentação, de negócio e de dados. Note que é uma arquitetura "N" camadas já conhecida de alguns, veja:

Esse desenho é parte de um conjunto de guias e artigos publicados semana passada no CodePlex, no link a seguir:

patterns & practices: App Arch Guide project
Ref.: https://www.codeplex.com/AppArch

Vale a pena conferir. Em breve, vamos discutir alguns tópicos desse material em detalhes, posicionando ainda as tecnologias LINQ, Entity Framework, Data Services, WCF, entre outras, além de conceitos como autenticação, autorização, mensageria, interface de serviços, etc.

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments

• Anonymous
  September 16, 2008
  Esse realmente é um tópico quente !

• Anonymous
  September 16, 2008
  Olá Felipe, tudo certo? Sem dúvida, lembrando as várias ferramentas que temos para organizar o desenvolvimento de soluções citamos:

1. Manuais de desenvolvimento
2. Guias livres de contexto / com contexto
3. Guias de automação
4. Arquiteturas de referência
5. Modelos de desenvolvimento e arquitetura
6. Frameworks de desenvolvimento
7. Linguagens Específicas de Domínio (DSL’s)
8. Fábricas de Software (Software Factories) Essa discussão está no contexto das arquiteturas de referência apenas mas mesmo assim, podemos considerá-la das mais importantes. Um Abraço! Waldemir.

• Anonymous
  September 22, 2008
  Waldemir... como você sabe estou envolvido com a construção de um framework de desenvolvimento, que se lembra um pouco com esse que você colocou... Só acho que existe um erro no desenho e abstração desse que você postou. Esta colocada a sub-camada service agents dentro da camada data. Acho que esta colocação é errada, pois um sevice agent pode não ter manipulação de dados nenhum. Pode ser uma função que você simplesmente avisa algo para alguem, sem ter algum retorno... dessa forma eu colocaria a services agent como um proxy para uma camada de business externa a aplicação...

• Anonymous
  September 22, 2008
  Olá Diogo, tudo certo? Obrigado pelos comentários no blog... De fato, estou me baseando nas recomendações do Service Layers Guidelines, conforme página abaixo: Service Layers Guidelines Ref.: http://www.codeplex.com/AppArch/Wiki/View.aspx?title=Service%20Layer%20Guidelines&referringTitle=Guidelines Através desse conjunto de patterns, o Service Agent é colocado como um elemento de interação com serviços externos, sendo responsavel pelo consumo de funcionalidades necessárias para execução de uma regra de negócio. Desse modo, o agente de serviço na camada de dados isola os detalhes de conexão com serviços externos envolvidos com uma regra de negócio ou processo de negócio, permitindo a adição de funcionalidades extras como formatação prévia, conversões de tipos, quebras de dados, etc. Na mesma camada de dados, são colocados os componentes de acesso a dados, para interação com as fontes de dados convencionais. Entendi seu ponto. Porém, agentes de serviços que apenas realizam notificações podem ser considerados subconjuntos do modelo, pois apenas exportam informações da aplicação para sistemas externos. Mas veja que podemos ajustar uma arquitetura de referência de acordo com a representação que desejamos. Assim, poderíamos colocar os agentes de serviços específicos para notificações na própria camada de serviços. Note que para a exportação de notificações, também teremos um contrato de serviço, um contrato de dados, assim como as demais considerações de proxy e publicação para esses agentes. Veja a descrição do Service Agent segundo o patterns & practices: Service agents: When a business component needs to use functionality provided by external service, you may need to provide some code to manage the semantics of communicating with that particular service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires. O que acha? Comprou a idéia? Um grande abraço! Waldemir.

• Anonymous
  November 03, 2008
  Olá pessoal, tudo certo? Recentemente, o patterns & practices publicou a versão 2.0, ainda Beta 1,