Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Sistemas com múltiplas arquiteturas
- 1. Você não deveria ter apenas uma arquitetura no seu sistema • Rafael Mueller – Inventti Soluções • rafael@inventti.com.br • @rmueller
- 5. A escolha das ferramentas
- 11. Qual o problema?
- 12. Qual o problema?
- 13. Qual o problema?
- 15. UI Layer Business Logic Layer Data Layer Quebrando seu sistema
- 16. Quebrando seu sistema Business Logic Servico A Data Layer UI Layer Layer Servico B Servico C Servico D
- 17. Com o que um serviço se parece? DA DA UI UI BL Servico A BL Servico B DA DA UI UI BL Servico C Servico D BL
- 18. Com o que um serviço se parece? DA UI UI BL Servico A BL IN DA Servico B NoS DA UI QL Servico C DA FA UI BL Servico D
- 19. Nossas arquiteturas DA UI UI BL Servico A BL IN DA Servico B NoS DA UI QL Servico C DA FA UI BL Servico D
- 21. Novos objetivos Homogêneo Modular Rápido Fácil Autonomia Tempo
- 22. Outras vantagens
- 23. Como dividir nossa aplicação em várias aplicações?
- 24. UI Servico A Servico B Como integrar os serviços? Servico C
- 25. Como integrar os serviços? Servico A Servico B Servico C Evento BUS / Broker / AtomServer
- 26. Como integrar os serviços? Servico B Servico A Servico C UI
- 27. Perguntas? Rafael Mueller – Inventti Soluções rafael@inventti.com.br @rmueller
Hinweis der Redaktion
- Como nascem os sistemas?Geralmente nos é passado alguma idéia do sistema que iremos desenvolver.No nosso caso, vamos imaginar o nascimento de um sistema de e-commerce social (já que hoje tudo precisa ser social).
- Após uma visão geral do nosso sistema, nós começamos a escolher quais serão nossas ferramentas de trabalho.Nós passamos um bom tempo pensando em quais ferramentas farão parte da nossa caixa de ferramenta, pois serão essas ferramentas que irão suportar nosso trabalho agora e para o resto da vida do software, então, nós não queremos fazer más escolhas.Então nós passamos 3 meses, analisando várias ferramentas, vendo o que é mais adequado para o nosso projeto de e-commerce.Beleza, caixa de ferramentas definida, começa o projeto.
- Além das ferramentas, nós vamos escolher nossa arquitetura, e geralmente se você pedir pra alguém sobre qual é sua arquitetura, a resposta é a padrão, com uma camada de UI, uma camada de negócio e a persistência.Tem um pessoal falando de CQRS, mas não vamos arriscar também (mostrar uma imagem de uma arquitetura CQRS).Já que tanta gente faz desta forma, vamos pegar nossas ferramentas e colocar nessa arquitetura.
- Quando nós vamos então começar a desenvolver, é que eu considero que nossos problemas começam a aparecer.Nós (se tivermos sorte) vamos conversar com o cliente, e ele começa a descrever o seu negócio, o que o software deve lhe auxiliar.Analista de negócio é procedural do que ele acha que precisa.Certo, mas então o cliente começa a descrever.No sistema, o CLIENTE poderá se cadastrar e então navegar pelos produtos (outra classe, com preço) do sistema.O cliente poderá então comprar o produto se ele tiver disponível (adicionar informação de estoque no produto, criar classe carrinho de compra e itens do carrinho de compra, vincular carrinho com cliente) e depois realizar a compra (adicionar histórico de produtos comprados no cliente)
- 8minTudo certo, após essas definições nós utilizamos nossos frameworks já selecionados e em 3 meses entregamos esse módulo para o cliente.Então ele percebe uma oportunidade de negócio, algo mais social e outras informações que ele precisa no sistema dele.Ele quer que os produtos tenha avaliação.Além disso, para FIDELIZAR os clientes, ele criou níveis de STATUS para os clientes, e cliente PRATA e OURO passarão a ter um desconto nas compras acima de R$150 reais.Ele também acha importante, que os clientes possam ter uma lista de amigos, para saber o que eles compraram, para mostrar as avaliações dos amigos em primeiro ao acessar um item...
- 10minE qualquer idéia nova que o cliente trouxer, nós já teremos as classes base do sistema pronta, geralmente é adicionar mais uma meia dúzia de atributos em nossa classe que nós já resolvemos o problema. O limite do nosso sistema, de nossas classes, são os limites do projeto.Neste ponto, digamos com 6 ~ 10 meses de desenvolvimento (de um sistema que deverá existir por ao menos meia década) nós já temos o caos.(Mostrar um ER complexo, talvez até alguns slides com vários)
- 12minSRP? EAGER LAZY LOADQuem já viu uma regra de negócio “O nome do produto só pode ter mais que 30 caracteres, se o nível de estoque for maior que 150”. Ou então “para a avaliação de um produto ser aceita, o usuário precisa ter feito um compra com C.C. e local de entrega sendo uma capital”?Não existe motivo pra isso tudo estar junto... Mesmo assim nós continuamos a salvar essas informações sempre juntas.Nesse ponto, se você trabalha com EF, Nhibernate também começam outros problemas, vou usar eager fetch ou lazy load? (explicar sobre os conceitos) Em alguns caso preciso eager, outro lazy, agora para cada lugar preciso saber exatamente o que usar ou não usar...
- 13 minCoesão e Acoplamento – nossas classes estão interligadas, de forma que não existe alteração em apenas um ponto do sistema, qualquer alteração irá impactar em várias classes.QUALQUER ALTERAÇÃO IMPACTA E MUITAS CLASSES
- 16minSOA e DDD – services e bounded contexts – formas novas e tão faladas de desenvolver software, tem em seu core algo em comum, que você não tem um sistema ou domínio, você tem vários sistemas (serviços) ou vários domínios. Isso é a base para esses dois assuntos, essa divisão do seu sistema em sistemas menores, com responsabilidades específicas.
- Você então precisa dar manutenção nesse sistema enorme, algo com uma complexidade gigante, que mesmo que o código escrito seja uma qualidade incrível, você terá problemas ao trabalhar com isso, devido a sua enorme complexidade.ATUALIZAR CASTLE WINDSORCADA STAKEHOLDER TEM UMA VISAO PRODUTOLIMITE DO SISTEMA É TODO ESCOPO DO PROJETOOs sistemas sempre tem muito stakeholders, cada um tem uma visão do que é um produto ou um cliente, nós não devemos ter a ilusão que nós vamos conseguir juntar tudo isso e modelar como algo único.Mesmo assim, mesmo sabendo que não estamos fazendo da forma correta, continuamos fazendo,e se continuamos fazendo sempre a mesma coisa, não podemos esperar que haja qualquer melhora.Claro que nós podemos também continuar fazendo desta forma e esperar ser movido para outro projeto, ir para outra empresa, ou já que o início do projeto foi tão bom, podemos até ser promovido.
- 20minSOFTWARE RESOLVE VARIOS PROBLEMAS, CADA PARTE COM FERRAMENTAS, TECNICAS DIFERENTESEH OBVIO QUE DEVERIAMOS TER SERVICOS, MAS NÃO FAZEMOS.Vocês não querem dar manutenção em algo gigante, é sempre melhor dar manutenção em algo menor.SOLUTION com 150 projetos.REFATORAÇÃO NÃO FEITA
- 23minVOLTAMOS ARQUITETURA PADRÃOQUEBRAR SISTEMA NÃO É COLOCAR MAIS UM CAMADA
- 25minREUSOQUESTOES DENTRO DE UM CONTEXTO/SERVICO
- O que exatamente devemos ter em um serviço? DOMÍNIOS SEPARADOS.CADA SERVICO ENXERGA SOMENTE AS INFORMACOES NECESSARIAS PARA SUA RESPONSABILIDADEEle terá * sua persistência própria, seu próprio banco de dados * lógica interna e separado * estratégias de implementação e domain models separado * Própria IU
- 30 minEle terá * Evolução e desenvolvimento separado * Opera autonomamenteEsses subsistemas compartilham o ID.
- 33 minNesse ponto, é importante sabermos que temos arquiteturas e problemas a serem resolvidos bem diferentes.A partir do momento em que nós quebramos um sistema em vários serviços, nós passamos a ter diferentes arquiteturas, onde algumas regras devem ser seguidas por todos serviços e outras regras cada serviço pode definir a sua.FIXAS – no nosso sistema como um todo, mesmo padrão de comunicação entre os serviços, estilo de UI, notificação de erros.VARIÁVEIS – é aquilo que compõe o sistema, um serviço pode trabalhar em .net asp.net mvc, outro rails, rails, nhibernate, nosql... Alguns terá MVVM -> UI -> Controller -> DTO -> Aplication Services -> Domain -> ORM -> DB, outro usa activerecord e salva direto no banco.Um módulo importante do sistema, ganha uma arquitetura mais forte, robusta, outro algo mais simples.
- 35minQuando eu comento sobre várias arquiteturas, as pessoas começam pensando “Meus Deus, então não terei padronização?! E o meu framework caseiro que estamos desenvolvendo na empresa a 5 anos, não vou reutilizado em todo lugar?!”MELHORES FERRAMENTAS PARA CADA TRABALHOREAPROVEITAR SKILLSMAIS FACIL REESCREVER* A idéia não é uma anarquia, mas que você possa selecionar melhor as melhores ferramentas para cada trabalho * Você quer reaproveitar skills.* É mais fácil você também depois reescrever alguma parte do sistema. É comum, depois de um tempo, as empresas quererem atualizar o software, depois de 10 anos, não querem mais remendar e querem fazer do 0. É muito mais simples, que essas reescritas sejam feitas por sub-sistemas do que reescrever toda uma estrutura. Algumas empresas partem para geração automática, ou ficam desenvolvendo algo por 12~24~36 meses sem aquilo sair de dentro da empresa. é um enorme desperdício de dinheiro. Sem contar, que quando ficar pronto, irá passar um tempo e pode ocorrer novamente essa reescrita, não faz sentido. Todos entendendo? Claro é tão óbvio, mas mesmo assim, nós não fazemos.
- 39 min(Imagem dos objetivos do projeto evoluem) * No início você está preocupado com simplicidade, que seja rápido e fácil desenvolver, homogeniedade... com o passar o tempo, você busca modularidade (seria tão bom se não tivesse essa dependencia, pois agora alterar isso quebra aquilo), decoupling (no início você não quer, pois é caso, custoso desenvolver isso no início)., autonomia (quando você está em produção, você quer atualizar somente uma parte, tirar um serviço e colocar outro no lugar. Você precisa de autonomia entre os serviços para conseguir Time to Market. Com um sistema enorme, você sempre precisa testar tudo, ver se não quebrou nada, com eles autonomos, vc pode atualizar somente uma parte do seu sistema), você quer poder suportar heterogêneos (você não quer isso, no início queremos tudo padrão, tudo igual. Mas depois, você quer suportar isso, talvez usar um bando noSQL, banco de dados grafos, ou uma linguagem funcional iria resolver facilmente o problema... mas você não pode utilizar). É muito difícil fazer essas coisas lá no final. Depois dele pronto, com um sistema pronto, você quebrar ele é muito difícil. * Isso significa que vocês estão trabalhando somente em um sistema, ou em vários sistemas que irão resolver um ou alguns problemas dos seus clientes?
- 40minDentro de 2, 3 anos, a tecnologia muda e você pode precisar de algo que não existia ou não estava maduro suficiente quando você iniciou o projeto.E no final, se tudo ficar realmente igual, você terá vários sistemas menores, mais simples, desacoplados, que podem evoluir, ou ficar estagnados, sumir, separadamente, sem que isso incomode os outros módulos. É muito mais fácil alguém começar em um projeto com 5 projetos do VS.Se você precisa fazer um exterme go horse, faça somente dentro de um contexto.
- 43BDUFAgile é contra, e eu também, mas nós precisamos pensar um pouco antes de escrever o código. Por experiência própria, é muito mais caro fazer a divisão dos serviços DEPOIS de você ter um serviço monolítico, ou mal formado.Comentar que eu comecei errado e deu um bom retrabalhoTradeOffs – No início irá gerar um trabalho maior, mas o nosso objetivo com um software é diminuir a complexidade total dele e não somente a inicial.
- 46 minNão existe request/response entre serviços.Não há dependencia entre serviços
- 50 min
- 51 minPRISM para desktopA melhor forma de integrar isso, é frontend integration. Deixa o browser fazer a integração. Isso permite um cache mais agressivo em algumas partes do sistema. Nós compartilhamos css, logos, js comuns.Problema com single sign-on. Em asp.net mvc, usando form authentication, é muito simples, usando o mesmo authentication machine. Mas com isso você está preso em .net e forms, então geralmente você tem um serviço que prove a autenticação.
- Mesmo que você não chega lá, mas escolha sempre a opção que deixa você mais perto disso, você terá um nível menor de complexidade, deixando seu tempo para o que é importante e não no dinossauro que o software se tornou.Mostrar aqui como deveria ser uma arquitetura no final, com os serviços conversando entre si.