Kilderson Sena
Cearense arretado e amante da programação. Full Stack Dev, Pai do Kauan Lucas, viciado em café, futebol e Rock'n Roll
UMA ABORDAGEM PRODUTIVA COM CLEAN ARCH, DDD E LARAVEL
Por: Kilderson Sena
REFLEXÕES
Partes das regras de negócio na View ou no controller? Impedindo assim reuso e potencializando duplicação de código?
Regras de negócio estavam diretamente "casadas" com o banco de dados? Dificultando criação de testes?
É arriscado ou seguro substituir uma biblioteca de sua aplicação sem ter que mexer em milhares de linhas de código?
(Por exemplo do moment.js)
Você já se deparou com as situações abaixo:
E para onde isso nos leva?
Dificuldade na evolução do produto
Se você passa ou já passou por isso, tá na hora de virar esse jogo!
Arquitetura de Software
"(...) minimizar os recursos humanos necessários para construir e manter um determinado sistema."
Robert C. Martin
Arquitetura de Software
"(...) são decisões que ao mesmo tempo são importantes e difíceis de mudar."
Martin Fowler
Clean architecture
É uma estratégia arquitetural orientado ao desacoplamento entre as regras de negócio e agentes externos como frameworks e bancos de dados.
Clean architecture
Separação da aplicação em
camadas lógicas
E a tal das camadas?
CAMADAS !== PASTAS
As camadas são LÓGICAS, camadas NÃO SÃO pastas!
E a tal das camadas?
"(...) o centro da sua aplicação não é o banco de dados. Não é ele e nem um ou mais frameworks que você pode estar usando. O centro da sua aplicação são os use cases."
Robert C. Martin
E a tal das camadas?
"(...) devem definir como as coisas são organizadas, como elas se relacionam e que responsabilidades elas devem ter."
Rodrigo Branas
Quem é tu mermo?
Kilderson Sena
🤓 CEO & CTO Astrotech Software House
👨🎓 Graduado em Análise e Desenv. Sistemas
🤘 Movido a café e Rockn'roll
👨💻 Programador há mais de 20 anos
👨👩👦 Esposo da Dayanny Pai do Kauan Lucas
fb.com/kilderson.sena
@derson_sena
@derson_sena
dersonsena
dersonsena-cabradev
cabra.dev
@cabra_dev
Quem é tu mermo?
Agradecimentos
Vinícius Dias
(PHP Rio)
Junior Grossi
(PHP MG)
Willian Correa
(PHP com Rapadura)
Marcel dos Santos
(PHP SP)
Rodrigo Branas
(branas.io)
Erandir Jr.
(PHP com Rapadura)
Pré-requisitos
- DTO (Data Transfer Object)
- Design Pattern Adapter (Wrapper)
- Single Responsibility Principle (S do SOLID)
- Dependency Inversion (D do SOLID)
- Domain-Driven Design (DDD)
Minha opinião
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
São objetos que servem para transferir dados de uma camada para outra.
São usados mais na "borda" das camadas para fazer a entrada e saída de dados de forma desacoplada.
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
class CreateOrderInputData
{
public function __construct(
public readonly string $orderId,
public readonly int $clientId
){
// Sanitizar, truncar os valores dos atributos...
// NADA de regra de negócios aqui!
}
}Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
É um padrão de projeto estrutural que permite objetos com interfaces incompatíveis colaborarem entre si.
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Interface incompatível
com aplicação
Interface esperada
nada aplicação
Aplicação
3th party
Adapter/Wrapper
Conciliação entre interfaces incompatíveis
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
"De todos os princípios, a SRP provavelmente é o menos compreendido.
Em geral, os programadores imaginam que todos os módulos devem fazer apenas uma coisa."
Fonte: Livro Clean Architecture
Robert C. Martin
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Fonte: Livro Clean Architecture
Robert C. Martin
"Historicamente, o SRP tem sido descrito como:
Um módulo deve ter uma, e apenas uma, razão para mudar."
(Um módulo deve ser responsável por um, e apenas um, ator.)
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Fonte: Livro Clean Architecture
Robert C. Martin
"Os sistemas mais flexíveis são aqueles em que as dependências de código-fonte se referem apenas a abstrações e não a itens concretos."
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Fonte: Livro Clean Architecture
Robert C. Martin
"É impraticável tratar essa ideia como uma regra, pois os sistemas de software dependem de muitas facilidades concretas."
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Fonte: Livro Clean Architecture
Robert C. Martin
"Por exemplo, a classe String no Java , DOMDocument e Array Object do PHP são concretas e não seria prático forçá-la a ser abstrata"
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
É uma abordagem focada na comunicação com especialistas do negócio
(Domain Experts)
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Entities (Entidades)
~> São artefatos que possuem identidade e estado, podendo ser construídas por outras Entidades ou Value Objects (Objetos de Valor).
~> O estado desses artefatos podem e vão mudar de acordo com seu ciclo de vida
!!! Alerta de polêmica !!!
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Entidades não tem absolutamente NADA a ver com mapeamento de um ORM ou um Active Record.
Entities (Entidades)
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Eloquent
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Doctrine
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
São objetos auto validaveis e imutáveis pois sua identidade está no(s) seu(s) valor(es), ou seja, se eu mudar um dos valores de um V.O. eu estou mudando ele inteiro.
Value Objects (Objetos de Valor)
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Repositories (Repositórios)
É uma abstração de persistência e consulta de dados.
Nesse ponto não sabemos como ou onde isso vai ser persistido, você só estará dizendo que haverá uma interação com uma mecanismo de armazenamento.
Pré-requisitos
DTO • Adapter • SRP • DIP • DDD
Anti-Corruption Layer (ACL)
ACL na Clean Architecture é o papel feito pela camada Interface Adapters, onde teremos adaptadores ou tradutores de uma camada para outra.
(Classe de Negócio)
SalePayment
(Classe de Persistência)
PagseguroApi
(API PagSeguro)
(Interface)
PaymentGateway
uffffaaa !!!
Agora respira e vamos falar de Clean Architecture
Fonte: Livro Clean Architecture
Robert C. Martin
interprise business rules
Supondo que estamos num domínio de vendas e temos cálculos de multa e juros. Se formos calcular numa ação de geração de uma NF no mundo real independente de ter sistema ou não regra continuaria a mesma.
Entities
USE cases
~> Não deve saber quem o está utilizando, se está consumindo JSON, XML, CSV, Texto puro
~> Não sabe que formato de dados será retornado, só retorna um DTO de Saída (Output Data) quando necessário
~> Lançam Exceções de Negócio
Use Cases
interface adapters
~> Fazem a "tradução" entre o mundo externo e as regras de negócio
~> Convertem dados para mecanismos de I/O
~> Análogo a ACL do DDD
Interface Adapters
Frameworks and Drivers
~> Essa é a camada mais Low Level
~> São frameworks e outras estruturas externas que fazem o I/O com aplicação
Frameworks & Drivers
E por onde começar?
Boilerplate Laravel
Domínio
"AirB2B" de prestadores de serviços
Seguindo a risca a sepação lógica e física das camadas
Domínio
Marketing Multinível
-> Mapeamento de Contextos (Context Mapping);
-> Event storming é ótimo para isso;
-> Dividir o projeto em contextos ou módulos;
-> Mesmos contextos delimitados do DDD;
-> Contextos NÃO se conversam diretamente;
-> Um "Shared Kernel" para servir os contextos;
Event Storming
Shipping
Bounded Context
Entities + Use Cases
Interface Adapters +
* Framewors and Drivers
Shipping
Bounded Context
Shipping Domain Layer
Shipping INFRA Layer
Mapeando Abstrações com implementações Concretas
eventos para comunicação entre os bounded contexts
Obrigado! =D
Kilderson Sena
fb.com/kilderson.sena
@derson_sena
@derson_sena
dersonsena
UMA ABORDAGEM PRODUTIVA COM CLEAN ARCH, DDD E LARAVEL [PHP Summit 2023]]
By Kilderson Sena
