O documento descreve os princípios da Clean Architecture, uma estratégia arquitetural que promove o desacoplamento entre as regras de negócio de uma aplicação e recursos externos. A Clean Architecture define camadas lógicas com entidades, casos de uso e adaptadores de interface que isolam as regras de negócio de tecnologias como bancos de dados e frameworks. Isso permite mudanças nesses recursos sem afetar o código de domínio e aumenta a testabilidade.

1. Rodrigo Branas – @rodrigobranas – youtube.com/rodrigobranas
Clean Architecture
The only way to go fast, is to go well

2. youtube.com/rodrigobranas
inscreva-se

3. Estamos buscando formas de reduzir a
complexidade, não de aumentá-la

4. "If you think good architecture is expensive,
try bad architecture"
Brian Foote

5. Não se desespere com tanto adapter,
composer, interactor, controller, gateway

6. Um dos primeiros computadores da história,
o ENIAC, começou a operar nos anos 40

7. Esse computador era programado por meio
de painéis com interruptores e fios

8. O que se fazia, sem internet, com um
computador nessa época?

9. Simulações para o decaimento de neutros
durante uma fissão nuclear

10. Cálculo da trajetória de mísseis

11. Previsão do tempo

12. Pelo jeito ninguém criou o computador para
compartilhar fotos ou fazer compras

13. O software evoluiu de interruptores e fios
para programas armazenados em cartões

14. Com o tempo, o código-fonte passou de
assembly para linguagens de nível mais alto

15. Tivemos muitas linguagens importantes nos
anos 50: FORTRAN, LISP, ALGOL e COBOL

16. As primeiras bibliotecas, permitindo o reuso
de código-fonte, também são dessa época

17. Além do reuso, garantir que o programa
funcionava era bem complicado

18. Edsger Dijkstra, um dos primeiros grandes
cientistas da computação, trabalhava nisso...

19. Ele observou que o uso de GOTO dificultava
os testes por conta da transferência
indiciplinada de controle

20. Os paradigmas de programação introduzem
um conjunto de regras e restrições

21. A programação estruturada usa controle de
fluxo, repetição e subrotinas para impor
disciplina na transferência direta de controle

22. Já faz bastante tempo que superamos os
limites da Lei de Moore...

23. Com isso começamos a adotar cada vez
mais o paralelismo nos nossos programas

24. Linguagens funcionais se baseiam em
uma outra forma de computação...

25. Enquanto a Máquina de Turing realiza mutação
de dados o Cálculo Lambda evalua funções

26. As linguagens funcionais impõe disciplina
sobre a atribuição e mutação de estado

27. Quais são as principais características da
programação orientada a objetos?

28. Encapsulamento, herança e polimorfismo

29. De certa forma temos tudo isso em outros
paradigmas de programação...

30. As linguagens OO impõe disciplina sobre a
transferência indireta de controle por meio
da sua característica mais importante,
que é o polimorfismo

31. É ele que permite a implementação de
plugins e drivers, basta criar um contrato

32. Aonde o SOLID entra nisso?

33. "Good software systems begin with clean
code. On the one hand, if the bricks aren’t
well made, the architecture of the building
doesn’t matter much. On the other hand,
you can make a substantial mess with well-
made bricks. This is where the SOLID
principles come in"
Robert Martin

34. O que é arquitetura de software?

35. Obviamente essa é uma definição difícil já
que cada um tem uma opinião diferente

36. "The goal of software architecture is to
minimize the human resources required to
build and maintain the required system"
Robert Martin

37. "Software architecture is those decisions
which are both important and hard to
change and if made poorly, will make a
project either succeed or fail, in a
needlessly expensive way"
Martin Fowler

38. "Architecture is about the important
stuff, whatever that is..."
Ralph Johnson

39. Ao longo dos anos, várias estratégias
arquiteturais foram idealizadas...

40. Estratégias Arquiteturais
• Hexagonal Architecture ou Ports and
Adapters (Alistair Cockburn)
• Onion Architecture (Jeff Palermo)
• DCI (Jim Coplien e Trygve Reenskaug)
• BCE (Ivar Jacobson)
• DDD (Eric Evans)
• Clean Architecture (Robert Martin)

41. Todas elas tem algo em comum...

42. Uma hierarquia onde as camadas de mais alto
nível conhecem camadas de baixo nível, não vice-
versa, criando um fluxo de controle ordenado,
permitindo o reuso e o desacoplamento e fazendo
com que o projeto fique organizado, aberto a
mudanças e fácil de manter e testar

43. É possível programar tudo no método que trata
uma requisição HTTP? Qual é o problema?

44. Você já trabalhou em um projeto onde:
• Parte das regras de negócio estavam
definidas em uma view, ou em um controller,
impedindo o reuso e favorecendo a
duplicação de código?
• Existia acoplamento entre as regras de
negócio e o banco de dados, impedindo a
criação de testes de unidade?
• Onde era praticamente impossível substituir
uma biblioteca sem ter que mexer em
milhares de linhas de código?

45. O que é a Clean Architecture?

46. A Clean Architecture é uma estratégia arquitetural
orientada ao desacoplamento entre as regras de
negócio da aplicação e os recursos externos por
meio de polimorfismo

47. Vamos relembrar o conceito de polimorfismo

48. Polimorfismo significa "diferentes formas", ou seja, as
implementações dependem de um contrato e a podem
variar de forma independente, por exemplo utilizando
padrões como Strategy ou Template Method

49. O principal objetivo é proporcionar
independência de qualquer recurso externo

50. Frameworks, bibliotecas, ferramentas,
interfaces gráficas, bancos de dados

51. Com isso favorecendo a mudança, mesmo
de um framework, além da testabilidade

52. O principal objetivo é isolar e proteger as
regras de negócio, no núcleo do software

55. As camadas da Clean Architecture são
lógicas, não tem relação com as pastas

60. Entities: responsável por concentrar os
principais participantes das regras de negócio
• Address your domain object
• Apply only logic that is applicable in general to the
whole entity (e.g., validating the format of a hostname)
• Plain objects: no framework or annotation

61. Use Cases: realizam a orquestração das
Entities na concepção das regras de negócio
• Represent your business actions: it’s what you can do
with the application. Expect one use case for each
business action
• Pure business logic, plain code (except maybe some
utils libraries)
• The use case doesn’t know who triggered it and how
the results are going to be presented (for example,
could be on a web page, or — returned as JSON, or
simply logged, and so on.)
• Throws business exceptions

62. Interface Adapters: fazem a tradução entre o
mundo externo e as regras de negócio
• Retrieve and store data from and to a number of sources
(database, network devices, file system)
• Define interfaces for the data that they need in order to apply
some logic. One or more data providers will implement the
interface, but the use case doesn’t know where the data is
coming from
• Implement the interfaces defined by the use case
• There are ways to interact with the application, and typically
involve a delivery mechanism (for example, REST APIs,
scheduled jobs, GUI, other systems)
• Trigger a use case and convert the result to the appropriate
format for the delivery mechanism
• the controller for a MVC

63. Frameworks and Drivers: são aspectos
puramente tecnológicos, não funcionais
• Use whatever framework is most appropriate
(they are going to be isolated here anyway)

64. Existem somente essas camadas?

65. As camadas de fora devem conhecer as
camadas de dentro, não o contrário

66. A interface gráfica e o banco de dados não
devem depender das entidades

67. Utilize mapas de chaves e valores, DTOs ou
até mesmo passando os dados diretamente

68. Conselhos
• Não se apegue aos nomes de padrões de projeto ou
nas estruturas de pastas que existem pela internet
• Aplique onde fizer mais sentido pra você, desacoplar
tudo pode criar muita complexidade sem necessidade
• Investa em testes de unidade desde o início, eles são
um bom indicador a respeito do desacoplamento das
camadas
• Não tenha medo de errar, entenda os princípios e corra
atrás dos resultados

69. "The center of your application is not the
database, nor is it one or more of the
frameworks you may be using. The center of
your application is the use cases of your
application"
Robert Martin

70. Obrigado!
Rodrigo Branas
Twitter: http://www.twitter.com/rodrigobranas
Instagram: http://www.instagram.com/rodrigobranas
YouTube: http://www.youtube.com/rodrigobranas
LinkedIn: http://br.linkedin.com/in/rodrigobranas
GitHub: http://www.github.com/rodrigobranas
Medium: http://www.medium.com/@rodrigobranas