Laravel para Aplicações de Grande Porte

Transcript

1. 1.

   Laravel para Aplicações de Grande Porte

2. 2.

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

   Decision6 CODECASTER @codecasts Diego Hernandes | @hernandev CTO @ Kino CODECASTER @ codecasts
3. 3.

   Mas, o que é Grande Porte ?

4. 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. 5.

   Perdendo o Controle!

6. 6.

   None
7. 7.

   None
8. 8.

   None
9. 9.

   Micro-services

10. 10.

    monolítico micro-services

11. 11.

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

    • Como distribuir?
12. 12.

    Módulos Módulo é uma palavra genérica de mais, varia muito

    com seu contexto e modo como é aplicado.
13. 13.

    Módulos Os namespaces do PHP + Composer deixam sua aplicação

    naturalmente modular.
14. 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. 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. 16.

    DDD

17. 17.

    None
18. 18.

    Domain Driven Development (ou algo inspirado...)

19. 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. 20.

    E onde eu enfio o resto da aplicação?... Como Views,

    Lógica de pagamentos, entre outros?
21. 21.

    SUPORTE FRAMEWORK APLICAÇÕES (UNIDADES) DOMÍNIOS

22. 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. 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. 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. 25.

    Por onde começar? $ composer create codecasts/laravel meu-projeto

26. 26.

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

27. 27.

    Perguntas