Clean Architecture sem ""Arrodeios""

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
Aplicação fica engessada e com código rígido.

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 da aplicação, recursos 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?

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

🤓 Senior Full Stack Engineer

👨‍🎓 Graduado em Análise e Desenv. Sistemas

🤘 Movido a café e Rockn'roll

👨‍💻 Programador há mais de 14 anos

👨‍👩‍👦 Esposo da Dayanny Pai do Kauan Lucas

fb.com/kilderson.sena

@derson_sena

@derson_sena

dersonsena

Senior Software Engineer

https://www.crewhu.com

dersonsena-cabradev

cabra.dev

@cabra_dev

Quem é tu mermo?

Quem é tu mermo?

8 Motivos para

usar o Yii2

yiiacademy.com.br/8-motivos-para-usar-o-yii-2

Aprenda Orientação a Objetos com Forma de Gelo

devtube.com.br/ebook-oo1.html

Agradecimentos

Vinícius Dias

(PHP Rio)

Junior Grossi

(PHP MG)

Willian Correa
(PHP BR)

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)
  • Um pouquinho de DDD

Minha opinião

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

São objetos que servem para transferir dados de uma camada para outra.

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Eu costumo por os dados primitivos, que não valide nada e seja imutável.

Objetivo dele é: receber os dados e levar para o(s) interessado(s).

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

São usados mais na "borda" da arquitetura para fazer a entrada de dados de forma desacoplada.

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

class CreateOrderInputData
{
  public function __construct(
    private string $orderId,
    private int clientId
  ){}

  public function getOrderId(): string
  {
    return this->orderId;
  }

  public function getClientId(): int
  {
    return this->clientId;
  }
}

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

Interface incompatível

com aplicação

Interface esperada

nada aplicação

Aplicação

3th party

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

(Classe de Negócio)

SalePayment

(API PagSeguro)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

(Classe de Negócio)

SalePayment

(Classe de Persistência)

PagseguroApi

(API PagSeguro)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

(Classe de Negócio)

SalePayment

(Classe de Persistência)

PagseguroApi

(API PagSeguro)

(Interface)

PaymentGateway

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

(Classe de Negócio)

SalePayment

(Classe de Persistência)

PagseguroApi

(API PagSeguro)

(Interface)

PaymentGateway

(Classe de Persistência)

GetNetApi

(API GetNet)

(API Cielo)

(Classe de Persistência)

CieloApi

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

A idéia é que você não marrete tudo numa única classe, criando uma classe Deus

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

(Classe de Negócio)

SalePayment

(Classe de Persistência)

PagseguroApi

(API PagSeguro)

(Classe de Negócio)

SalePayment

(Classe de Persistência)

PagseguroApi

(API PagSeguro)

(Interface)

PaymentGateway

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

"Uma coisa é entender a Essência do Negócio e outra coisa é codar esta mesma essência de forma adequada"

Rodrigo Branas

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

~> 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

Entities (Entidades)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

  • Um pagamento pode estar aberto e depois ficar pago;
  • Um cliente pode estar adimplente e depois inadimplente;
  • Uma venda pode estar pendente ou cancelada;

Entities (Entidades) Exemplos:

!!! Alerta de polêmica !!!

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Entidades não tem absolutamente NADA a ver com mapeamento de um ORM.

Entities (Entidades)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Esse termo foi "patenteado" pelos ORM's, mas lá nada mais é do que um Mapper ou um espelho de uma classe para uma tabela do banco de dados.

Entities (Entidades)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

São objetos auto validaveis e imutáveis pois sua identidade está no seu valor, ou seja, se eu mudar o valor de um V.O. eu estou mudando ele inteiro.

Value Objects (Objetos de Valor)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Geralmente são usados para compor as Entities, por exemplo:

Value Objects (Objetos de Valor)

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Aggregates (Agregados)

De forma resumida é um conjunto de Entidades que colaboram entre si podendo até ser tratados como uma unidade.

Formam um contexto transacional.

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Aggregates (Agregados)

A tendência natural é que quando essa entidade for abastecida lá no repositório eu estarei lidando com Agregados, ou seja, com o "Lider da Tribo"

(Aggregate Root)

Pedido

(Entidade)

ItemPedido

(Entidade)

Desconto

(Entidade)

Frete

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Repositories (Repositórios)

É uma abstração de persistência de dados. Nesse ponto não sabemos como ou onde isso vai ser persistido, você só estará dizendo que haverá uma persistência

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Repositories (Repositórios)

O objetivo dessa abstração é desacoplar o seu domínio da sua camada de infraestrutura.

Pré-requisitos

DTO • Adapter • SRP • DIP • DDD

Application Service

Também chamadas de use case, aqui será feita a tal da "Dança das entidades" para algum fim, por exemplo:

fazer matrícula, efetuar login, cancelar venda e etc;

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

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 eu for calcular isso numa ação de venda, de NF, de estoque a regra continuaria a mesma. A aplicação muda mas a regra de juros e multa não muda.

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 requerido

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

SugesTão de pastas

Entities + Use Cases

Interface Adapters

Framewors and Drivers

Entrypoint / Main Layer

Clash Royale

Use case #1 - Create Deck

Deck: para criar um deck é preciso ter: capacidade, cards, dono e possibilidade de mostrar a média de elixir com 1 casa decimal.

Card: um card representa um personagem com os atributos: nome, nível (nível máx: 13) e elixir (nível máx: 9)

Player: todo deck pertence a um player com os atributos: nome, qtd. troféus e o clã que ele pertence

Use case #2 - Do Battle

Deck Player #1

Deck Player #2

Player #1

Player #2

REGRAS DA BATALHA

> É obrigatório adicionar exatamente 2 decks
 

> A diferença entre os troféus dos players NÃO pode ser maior que 800
 

> Player #1 e Player #2 não pode ser a mesma pessoa

 

RESULTADO DUELO

> Deverá informar qual player e deck venceu

> Deve somar 50 troféus do player vencedor

> Deve subtrair 5 troféus do player perdedor

Obrigado! =D

Kilderson Sena

fb.com/kilderson.sena

@derson_sena

@derson_sena

dersonsena

Clean Architecture sem "Arrodeios" [PHP Summit 2021]

By Kilderson Sena

Made with Slides.com

Clean Architecture sem "Arrodeios" [PHP Summit 2021]

  • 706

More from Kilderson Sena