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
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
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?
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
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
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)
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