A palestra discute a importância da arquitetura de software no dia a dia de desenvolvimento, especialmente no que diz respeito à comunicação entre a equipe, codificação e projeto do software. Uma boa arquitetura torna o sistema fácil de entender, desenvolver e manter, além de viabilizar as necessidades de negócio. É necessário ter uma linguagem compartilhada na equipe e validar soluções com pequenas implementações.

1. Uma linha tênue
entre
arquitetura de software
e o dia a dia dev
PHP COMMUNITY SUMMIT 2021
EDUARDO CESAR
ENGENHEIRO DE SOFTWARE - ZARP

2. MAS O QUE É ARQUITETURA DE SOFTWARE?

6. A software architecture is an abstraction of the run-time
elements of a software system during some phase of its
operation. A system may be composed of many levels of
abstraction and many phases of operation, each with its
own software architecture.
Architectural Styles and the Design of Network-based Software Architectures
ROY FIELDING

7. DURANTE O DESENVOLVIMENTO DE SOFTWARE

8. LEITURA E ENTENDIMENTO DE CÓDIGO
CODIFICAÇÃO
MAIS ENTENDIMENTO DA PARTE, E MENOS DO TODO

9. JÁ PARAMOS PARA NOS PERGUNTAR….

10. Por que devemos refletir sobre arquitetura de software, principalmente do ponto de
vista de quem está escrevendo código no dia a dia?
OU AINDA
Por que arquitetura de software acaba sempre sendo um dos pontos que mais podem
influenciar um projeto?

11. Por que devemos refletir sobre arquitetura de software, principalmente do ponto de vista de quem
está escrevendo código no dia a dia?
...A ARQUITETURA DEVE FACILITAR O DESENVOLVIMENTO DESSE SOFTWARE PELAS
EQUIPES DE DESENVOLVEDORES.
Uncle Bob - Clean Architeture

12. Por que arquitetura de software acaba sempre sendo um dos pontos que mais podem influenciar um projeto?
...Uma boa arquitetura torna o sistema fácil de entender, fácil de desenvolver, fácil de
manter e fácil de implantar.
Uncle Bob - Clean Architeture

13. ARQUITETURA E NEGÓCIO

14. A IMPORTÂNCIA DAS DECISÕES
ESCOLHAS ERRADAS NORMALMENTE DERIVAM DE UM MAL
ENTENDIMENTO DO NEGÓCIO

15. EVITE
OTIMIZAR DE FORMA PREMATURA
TÃO POUCO
SE DEIXE LEVAR PELO “MODISMO” DA INDÚSTRIA

16. OTIMIZAR PREMATURAMENTE
ANTECIPAR PROBLEMAS QUE NEM PODEM VIR ACONTECER
NORMALMENTE EXCEDENDO ENGENHARIA
AGREGA COMPLEXIDADE E TEMPO QUE PODEM SER DESCARTADOS
(ao menos nesse momento)

17. NEM SEMPRE A MAIS RECENTE NOVIDADE DO MERCADO É NECESSÁRIA
PARA O SEU SOFTWARE

18. TENHA EM MENTE QUE….

19. AS DECISÕES SOBRE FERRAMENTAS E, QUAIS CONCEITOS SE APLICAM
DEVEM SER TOMADAS COM BASE NO PROBLEMA EM QUESTÃO

20. ATENTAR A POSSÍVEIS FALHAS DE NEGÓCIO
MUITAS FERRAMENTAS UTILIZAM CONCEITOS QUE PODEM NÃO SER O
MELHOR PARA O NEGÓCIO EM QUESTÃO

21. A ARQUITETURA DEVE SEMPRE VIABILIZAR
AS NECESSIDADES DE NEGÓCIO, E NÃO JOGAR CONTRA

22. A TENUIDADE DO PENSAMENTO

23. NA COMUNICAÇÃO

24. ...É NECESSÁRIO TER UMA LINGUAGEM VERSÁTIL COMPARTILHADA
PELA EQUIPE E UMA EXPERIÊNCIA ATIVA COM A LINGUAGEM QUE
RARAMENTE ACONTECEM EM PROJETOS DE SOFTWARE.
ERIC EVANS - Domain Driven Design

25. NA CODIFICAÇÃO

26. A ARQUITETURA DE SOFTWARE COMEÇA COM CÓDIGO
UNCLE BOB - CLEAN ARCHITECTURE

27. NO PROJETO

28. PENSE EM COMO SERÃO ENTREGUES OS
NOVOS RECURSOS

29. PENSE EM GOVERNANÇA

30. VALIDE SUAS SOLUÇÕES ATRAVÉS DE PEQUENAS
IMPLEMENTAÇÕES

31. OBRIGADO A TODOS!
EDUARDO CESAR
github.com/bolinha1
/in/eduardo-cesar-oliveira
eduardo.oliveira@zarpsystem.com.br
www.zarpsystem.com.br
ESTAMOS CONTRATANDO!!!