Laravel para Aplicações de Grande Porte

Laravel para Aplicações de Grande Porte

F803c45d62a468e0cb990398c004bd3e?s=128

Vinicius Reis

October 08, 2016
Tweet

Transcript

  1. Laravel para Aplicações de Grande Porte

  2. Quem Somos Vinicius Reis | @vinicius73 Engenheiro de Aplicações @

    Decision6 CODECASTER @codecasts Diego Hernandes | @hernandev CTO @ Kino CODECASTER @ codecasts
  3. Mas, o que é Grande Porte ?

  4. Mas, o que é Grande Porte? - Aplicações de complexidade

    média a moderada. - Aplicações com muitas funcionalidades. - Aplicações com muitas regras de negócio. - Aplicações com lógica de domínio complexas. - Aplicações que pretendem evoluir - Aplicações de ‘longo prazo’
  5. Perdendo o Controle!

  6. None
  7. None
  8. None
  9. Micro-services

  10. monolítico micro-services

  11. Módulos • O que é um módulo? • Como organizar?

    • Como distribuir?
  12. Módulos Módulo é uma palavra genérica de mais, varia muito

    com seu contexto e modo como é aplicado.
  13. Módulos Os namespaces do PHP + Composer deixam sua aplicação

    naturalmente modular.
  14. Módulos Tudo depende da estratégia de modularização. Tem que se

    não considerar a comunicação e dependências entre os “módulos” isso pode comprometer o uso e distribuição dos módulos.
  15. Módulos, problemas com responsabilidades... A página inicial do módulo de

    FÓRUM deve carregar uma lista dos últimos posts da aplicação (do módulo BLOG). BLOG e FÓRUM são módulos separados, mas agora eles precisam se comunicar. Como fica o reúso deles? Além disso, ambos precisam do módulo de USUÁRIOS....
  16. DDD

  17. None
  18. Domain Driven Development (ou algo inspirado...)

  19. Pensando em Domínios - Usuários - Grupos - Permissões -

    Fórum - Perguntas - Respostas - Blog - Categorias - Tags - Comentários Um domínio é o “assunto/contexto” de um determinado negócio
  20. E onde eu enfio o resto da aplicação?... Como Views,

    Lógica de pagamentos, entre outros?
  21. SUPORTE FRAMEWORK APLICAÇÕES (UNIDADES) DOMÍNIOS

  22. Aplicações (Unidades) - A principal responsabilidade das Unidades é a

    comunicação entre usuários (que também podem ser outras aplicações) e as outras camadas. - A camada de aplicação não tem intenção de ser portável para outras plataformas e tecnologias, visto que uma vez centralizadas as regras no domínio, a camada de aplicações passa a ser fina. Camada de I/O do Software Comumente é a camada HTTP, mas também pode ser uma camada acessível via terminal. Pode ser considerada uma camada “burra”, não possui regras de negócio.
  23. Camada de Suporte Exemplos: - View Presenters - Base de

    repositórios e models - Camada de Pagamentos - Sistema de Notificações - Qualquer coisa que possa ser transformada em um pacote de uso genérico. Pacotes ‘in-house’. Classes que não se encaixam na camada de domínio, existem para centralizar esse tipo de rotina. Podem ser facilmente distribuídos como pacotes composer.
  24. Dependência entre Camadas Support Domain Units Support não deve depender

    do domínio ou das Unidades Domínio pode depender de Suporte, mas não das unidades Unidades podem depender de ambos suporte e Domínio
  25. Por onde começar? $ composer create codecasts/laravel meu-projeto

  26. Show me the code! https://github.com/codecasts/codecasts

  27. Perguntas