Onion Architecture

Esta e uma arquitetura de software muito interessante que deveria ser assunto de uma discusso;
Texto traduzido de : Jeffrey Palermo

Falei vrias vezes de um tipo especfico da arquitetura que chamo "a Arquitetura de Onion". Encontrei que ele leva a mais aplicaes que pode ser mantido desde que ele acentua a separao de assuntos em todas as partes do sistema. Devo estabelecer o contexto do uso desta arquitetura antes do processo. Esta arquitetura no apropriada para pequenos sites web. apropriado para aplicaes de negcios duradouras bem como aplicaes com o comportamento complexo. Ele acentua o uso de interfaces de contratos de comportamento, e ele fora o externalization da infraestrutura. O diagrama que voc v aqui uma representao da arquitetura em camadas tradicional. Isto a arquitetura bsica que vejo o mais freqentemente usado. Cada camada subseqente depende das camadas abaixo dele, e logo cada camada normalmente depender de alguma infraestrutura comum e servios de servio. O grande desconto a esta arquitetura em camadas superior abaixo a unio que ele cria. Cada camada ligada s camadas em baixo dele, e cada camada muitas vezes ligada a vrios assuntos de infraestrutura. Contudo, sem unio, os nossos sistemas no fariam algo til, mas esta arquitetura cria a unio desnecessria. O ofensor mais grande (e o mais comum) a unio de UI e lgica de negcios ao acesso a dados. Sim, UI ligado ao acesso a dados com esta aproximao. As dependncias transitivas so ainda dependncias. O UIno pode funcionar se a lgica de negcios no estiver l. A lgica de negcios no pode funcionar se o acesso a dados no estiver l. Estou ignorando intencionalmente a infraestrutura aqui porque isto tipicamente varia do sistema ao sistema. O acesso a dados modifica-se freqentemente. Historicamente, a indstria modificou tcnicas de acesso a dados pelo menos cada trs anos; por isso, podemos contar com precisar de modificar o acesso a dados trs anos de agora para qualquer sistema so, duradouro isto crtico da misso do negcio. Muitas vezes no guardamos sistemas atualizados porque impossvel fazer. Se a unio prevenir facilmente fazer um upgrade de partes do sistema, ento o negcio no tem nenhuma escolha s deixar o sistema ficar para trs em um estado do mau estado. Isto como os sistemas de legado ficam passados, e conseqentemente eles so reescritos. Proponho uma nova aproximao da arquitetura. Honestamente, no completamente novo, mas estou propondo-o como um modelo denominado, arquitetnico. Os modelos so teis porque ele d a profissionais de software um vocabulrio comum com que comunicarse. H muitos aspectos Arquitetura de Onion, e se tivermos um termo comum para descrever esta aproximao, podemos comunicarnos mais efetivamente. O diagrama esquerda representa a Arquitetura de Onion. A premissa principal que ele controla a unio. A regra fundamental consiste em que todo o cdigo pode depender de camadas mais centrais, mas o cdigo no pode depender de camadas alm disso fora do ncleo. Em outras palavras, toda a unio em direo ao centro. Esta arquitetura descaradamente influenciada em direo programao orientada ao objeto, e ele pe objetos antes de todos os outros.

No mesmo centro vemos o Modelo de Domnio, que representa o estado e combinao de comportamento que verdade de modelos da organizao. Em volta do Domnio Modelo so outras camadas com mais comportamento. O nmero de camadas no ncleo aplicado variar, mas vai se lembrar de que o Modelo de Domnio o mesmo centro, e desde que toda a unio em direo ao centro, o Modelo de Domnio s ligado a se. A primeira camada em volta do Modelo de Domnio tipicamente onde encontraramos interfaces que fornecem o objeto comportamento que salva e recupera, chamado interfaces de repositrio. O comportamento de economia de objeto no est no ncleo aplicado, contudo, porque ele tipicamente implica um banco de dados. S a interface est no ncleo aplicado. Fora nas bordas vemos UI, Infraestrutura, e Testes. A camada exterior reservada para coisas aquela modificao muitas vezes. Estas coisas devem ser intencionalmente isoladas do ncleo aplicado. Fora na borda, encontraramos uma classe que implementa uma interface de repositrio. Esta classe ligada a um determinado mtodo do acesso a dados, e por isso ele reside do lado de fora do ncleo aplicado. Esta classe implementa a interface de repositrio e -lhe por meio disso ligada. A Arquitetura de Onion confia pesadamente segundo o princpio de Inverso de Dependncia. O ncleo aplicado precisa da implementao de interfaces principais, e se os que implementam classes residirem nas bordas da aplicao, precisamos de algum mecanismo para injetar aquele cdigo no tempo de execuo portanto a aplicao pode fazer algo til. O banco de dados no o centro. externo. Externalizing o banco de dados pode ser uma modificao verdadeira de algumas pessoas acostumadas ao pensamento de aplicaes como "aplicaes de base de dados". Com a Arquitetura de Onion, no h nenhuma aplicao de base de dados. H aplicaes que poderiam usar um banco de dados como um servio de armazenamento mas s embora algum cdigo de infraestrutura externo que implementa uma interface que faz sentido ao ncleo aplicado. Separando a aplicao do banco de dados, o sistema de arquivos, etc., abaixa o preo da manuteno da vida da aplicao.Externalizing the database can be quite a change for some people used to thinking about applications as "database applications". With Onion Architecture, there are no database applications. There are applications that might use a database as a storage service but only though some external infrastructure code that implements an interface which makes sense to the application core. Decoupling the application from the database, file system, etc, lowers the cost of maintenance for the life of the application. Alistair Cockburn escreveu um bocado sobre a arquitetura Hexagonal. A arquitetura hexagonal e a Arquitetura de Onion compartilham a seguinte premissa: a infraestrutura de Externalize e escreve o cdigo de adaptador para que a infraestrutura no fique justamente ligada. Estarei escrevendo mais sobre a Arquitetura de Onion como uma aproximao revelia para construir aplicaes empresariais. Ficarei no espao de sistema de empresa e toda a discusso residir naquele contexto. Isto torna-se mesmo mais interessante quando h mltiplos processos que compem um sistema de software nico. CodeCampServer usa a Arquitetura de Onion. Se voc estiver procurando uma aplicao cheia, de trabalho como um exemplo, por favor d uma olhada. O exemplo prtico que no pus antes de voc tomado diretamente de CodeCampServer. uma fatia estreita, vertical de um exemplo. Estou guardando o alcance pequeno para ser digestvel. Comearei com um diagrama portanto voc pode entender onde todo o cdigo reside dentro das camadas da Onion.

CodeCampServer usa o ASP.NET MVC Armao, portanto SpeakerController parte da interface de usurio. Este controlador ligado ao ASP.NET MVC Armao, e no h nenhuma obteno em volta disto. SpeakerController depende de IConferenceRepository e IUserSession (e IClock, mas omitiremos isto). O controlador s depende de interfaces, que so definidas no ncleo aplicado. Lembre-se de quetodas as dependncias so em direo ao centro. Chame a sua ateno ao ConferenceRepository e classes UserSession. Note que eles esto em camadas do lado de fora do ncleo aplicado, e eles dependem das interfaces tambm, para que eles possam implement-los. Estas duas classes cada instrumento uma interface mais perto para o centro do que se. No tempo de execuo, a nossa Inverso do container de Controle olhar para o seu registro e construir as classes prprias para satisfazer as dependncias de construtor de SpeakerController, que o seguinte:
public SpeakerController(IConferenceRepository conferenceRepository, IUserSession userSession, IClock clock) : base(userSession) { _conferenceRepository = conferenceRepository; _clock = clock; _userSession = userSession; }

No tempo de execuo, o container IoC resolver as classes que implementam interfaces e os passam no construtor SpeakerController. Neste momento, o SpeakerController pode fazer o seu emprego. Baseado nas regras da Arquitetura de Onion, os SpeakerController _could_ usam UserSession diretamente desde que est na mesma camada, mas ele no pode usar ConferenceRepository diretamente. Ele deve confiar em algo passagem externa em um exemplo de IConferenceRepository. Este modelo usado em todas as partes, e o container IoC faz este processo sem costura. No fim desta srie, planejo publicar um sistema de trabalho cheio que adere ao modelo de Arquitetura deOnion. Os sistemas que construmos para clientes usam esta aproximao, mas no estou na liberdade de discutir aquele cdigo, portanto trabalharei uma aplicao de referncia para aqueles de vocs que preferem uma soluo de Estdio Visual concreta de digerir.