Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude

Criando software para o futuro com DDD,
Arquitetura, Patterns, e Atitude
Pablo Dall'Oglio
@pablodalloglio fb/pablodalloglio

Adianti Solutions Ltda © Pablo Dall'Oglio Criando software para o futuro #2
This is not about...
●
Aquele Framework Javascript lançado ontem
– Embora certamente exista um!
●
Uma nova linguagem de programação
– Embora exitam várias!
●
Aquela tecnologia que ninguém conhece ainda
– Não sou vidente!
●
A nova onda do desenvolvimento
– Não sou vidente!
Não é sobre
os outros...
É sobre você

O que abordaremos
●
Atitude e cultura (Clean code, boas práticas, padrões).
●
Modelagem de domínio e arquiteturas de software.
●
Design Patterns, separation of concerns.

Problemas a resolver
●
Software orientado a tabelas.
●
Softwares cresce / Equipe rotaciona.
●
Requisitos mudam / Tabelas brotam.
●
Modelagem deteriora.
●
Resolve tickets, cria bugs.
●
Tecnologia ficou pra trás.
●
Manutenção é problema.
●
Perda de credibilidade.
●
Big spaghetti code.
Isso gera
Insegurança
raiva

Problemas a resolver

O básico antes
●
Dar bons nomes as coisas - fácil de identificar.
●
Colocar as coisas nos lugares corretos - fácil de localizar.

O pessoal tem dificuldades
class TabbedForm2
class SubscriptionsAndCreditsManager
class AbstractFlushClearCacheMessageBuilderOnTransactionSupport
function SetMetafileBitsBetter()
function hashPasswordForStoringInDatabase()
function accessCheckByTypeResultListAndAuditAlarmByHandle()
function InsertImportQueueRecord()
function processa()

Outros tem pressa
●
I'll fix it later.
●
Depois para alguns é nunca.
●
Depois é pretexto.
●
Eu sei o que isso significa,
e isso basta.
●
Os outros que se esforcem para
entender minha genialidade.
●
Por que cargas d'agua eu fiz isso?!?

O software você quer amanhã
●
Um software que eu consiga:
– ... ler
– ... manter
– ... trocar partes
●
Um software que eu não precise:
– ... matar quem fez
– ... jogar tudo fora
Legível
Curto
Desacoplado

Comece com boas práticas
●
Single Responsability (SubscriptionsAndCreditsManager).
●
High Cohesion (Modelo com HTML, UI com lógica).
●
Métodos devem fazer UMA coisa.
●
Métodos não devem ter MUITOS parâmetros (DTO).
●
Usar Exceptions, não códigos de retorno, não HTML.
●
Método dizer o que faz, não como faz (...forStoringinDatabase).
●
Use Nomes precisos.
●
Use nomes fáceis de encontrar (pense nos outros e em você).
●
Use nomes pronunciáveis:
– private genDMYHS()
– private generateTimestamp()

Coesão coincidental
●
Há pouca ou nenhuma relação entre as coisas.
class SuperMegaHiperUtil
{
public static function UTF8ToISO($texto)
{
// ...
}
public static function media($numeros)
{
// ...
}
public static function converteData($from, $format)
{
// ...
}
}

E mantenha tudo separado
●
Após organizar as coisas.
●
É preciso fazê-las independentes, pelo menos tentar.
Alguém
sempre diz:
mas tá
funcionando

E mantenha tudo separado
●
Bibliotecas evoluem.
●
Não fique amarrado.
●
Separe, crie abstrações.
●
Facilite a substituição.
●
Pense em você em 5 anos.

Modelos
Não existem um modelo de
arquitetura a ser copiado?

Layered Architecture
Separation
of concerns

Camadas
● Por que não juntar em 2 ou menos camadas?
●
Misturar apresentação e negócio, amarra no Frontend.
●
Misturar negócio e persistência, amarra no DB engine.
● Separar permite substituir.
●
Substituir a camada de apresentação para outro device.
● Substituir o engine de persistência para outro BD.

MVC
● Criado por Trygve Reenskaug no Smalltalk em 1979.
●
Após uma visita à Xerox �.
●
Rails popularizou.
● Frameworks
eclodiram.

MVC

Onde eu coloco isso?
●
Muitos acharam que o software teria só essas camadas.
●
Mesmo assim, as pessoas não sabiam onde colocar as coisas.
●
Isso é responsabilidade da Model? Da controller?
●
Onde vai a regra de negócio?
●
E a comunicação com bibliotecas externas?

DDD
●
E aí veio o Eric Evans e baixou a poeira.
●
Aumentou o nível da discussão.
●
"O design é o código, e vice-versa."
2003 Evans
2013 Vernon

DDD é trocar a ficha
●
Mudança de mindset.
●
A grande mudança está em suas mãos;
●
Não é sobre um Framework específico.
●
Não é sobre desenhar diagramas.
●
Trata de modelagem, de arquitetura.
●
Criar modelos organizados e flexíveis.

DDD é bom para anemia
●
Qual o problema deste código?
●
Parece tão bonito:
$venda = VendaDao::find($id);
$venda->setSituacao(Venda::CANCELADA);
$venda->setDataFinal(date('Y-m-d'));
foreach ($venda->getContas() as $conta) {
$conta->estorna();
}
VendaDao::save($venda);
Qual o
Use Case?

●
Os métodos são genéricos;
●
Não transmitem intenção;
●
Qual contexto de negócio ele é usado;
●
O que quer dizer o conjunto de chamadas?
●
Os objetos são só carregadores de dados de tabelas.
●
É no cliente que está a maioria da lógica (decisão)?
●
Quem executa que determina todo o fluxo.
●
O método deve revelar a intenção do contexto.

●
Foca nos atributos, não no comportamento.
●
Não explica a intenção do cenário.
●
Depende do desenvolvedor entender.
$total = $venda->getTotal();
for ($n=1;$n<=$parcelas; $n++)
{
$vcto = date(...);
$conta = new Conta;
$conta->setValor($total/$parcelas);
$conta->setOrigem($venda);
$conta->setVencimento($vcto);
$conta->save();
}
$venda->setStatus(Conta::FATURADA);

●
Essas coisas precisam estar encapsuladas
class Venda
{
// ...
function gerarContasReceber($parcelas)
{
for ($n=1;$n<=$parcelas; $n++)
{
// ...
}
}
}
$venda->gerarContasReceber($parcelas);
Tradicionalmente na
Entidade

Entity
●
É um objeto que pode mudar ao longo do tempo;
●
Possui com identidade única (unicidade);
●
Identity gerada pela App (UUID, GUID), pelo BD (Sequence);
●
Identity não deve ser gerada pelo usuário (imutável);
●
Seus atributos podem mudar, mas sua identidade permanece;
●
Identidade usada em logs, cache, auditoria, rastreabilidade;
●
Chave simples, e sem significado para o negócio;
●
Cache, manutenção cadastros, logs, REST API.

Value Object
●
Atributo que mede, quantifica ou descreve algo;
●
Não tem identidade, não precisa ser distinguido;
●
Não referenciado por outros do sistema;
●
Deve ser tratado como um escalar;
●
Seus atributos só fazem sentido juntos:
– Ex: Valor + Currency
●
Pode ser serializado;
●
Exemplos:
– Address, Color, Money
– Clone dos dados de um cliente de NF
Vale pelo que
contém, não
pelo que é

Value Object
class Pessoa extends Entity
{
private $nome;
private $endereco; // Value Object
// ...
}
CREATE TABLE pessoa
(
id serial primary key not null,
nome text not null,
endereco_rua text,
endereco_cep text,
endereco_numero text
)
CREATE TABLE pessoa
(
id serial primary key not null,
nome text not null,
endereco json
)
Jeito A
Jeito B

Aggregates
●
Grupo de objetos relacionados.
●
Tratado como um todo.
●
Quando deleta uma venda, deleta os itens?
●
Quando deleta uma pessoa, deleta os endereços?
●
É mais fácil pensar em forma de grupo;
●
Cuidado para não fazer tudo como Aggregate;
●
Ex: Produto <has> Sprint, Produto <has> Backlog item, Produto
<has> Release.
●
O root aggregate pode ficar tão grande, que…
●
Um save pode ter centenas de operações de persistência.
●
Root aggregate grande limita performance;

Aggregates
●
O root gerencia agregados;
●
Diferentes usuários editando diferentes partes;
●
Salva em 1 único commit;
●
Diferentes transações;
●
Lost updates.
Transações
diferentes

Aggregates
●
Temos mais root aggregates;
●
Sem aggregate em excesso:
– um user mexe num sprint
outro a release…
Itens que precisam
estar em conjunto.
interdependentes.

Repositories
●
Um local onde se guarda coisas para buscar depois;
●
Necessário um Critério (Query Object) para buscar;
●
Repositório pode ser BD rel, mongo, Redis, XML;
class RelationalRepository
{
public function load(Criteria $c) {}
public function delete(Criteria $c) {}
public function size(Criteria $c) {}
public function add(Entity $object) {}
public function remove(Entity $object) {}
}
class PessoaRepository extends Repository
{
}
DAO não é Repos
É só um
wrapper ao redor
de tabelas.
data-centric

Services
●
Prestado por alguém.
●
Fornecido para alguém.
●
Sabe aquela lógica?
●
Que não encaixa na Entity.
●
Tornariam ela grande.
●
Você não quer por na Controller.
●
Parece que não tem lugar pra ela?
●
Isso pode ser um servico.
●
Domain services, Application Services, e
Infrastructure Services.
●
Serviços não possuem estado (Stateless).

Domain Services
●
Faz parte do Domínio.
●
Encapsula Lógica de negócio.
●
Lógica que não tem espaço em uma Entity.
●
Não é CRUD.
●
É operação de negócio.
●
É Stateless.
●
É um bom lugar para regras de negócio.
●
Não controla transação, sessão, segurança.
●
Processamento, transformações, cálculos.
Ofertado
pelo
domínio

Domain Services
Entity:
class Venda
{
function cancela()
// verifica se pode ser cancelada
// altera status, dt. Cancelamento
// anula comissão
// registra movimentação
}
Domain Service:
class VendaService
{
function cancela( id )
-> Venda::cancela()
-> FinanceiroServices:estornaTitulos() // Verifica se tem títulos, estorna
-> EstoqueServices::baixaEstoque() // Rolllback estoque
}
Tem lógica de domínio
Envolve mais coisa
Tem lógica de domínio

Application Services
●
Não tem lógica de domínio;
●
É mais magra (coordena);
●
Voltado para disponibilização externa;
●
Usa o Domínio;
●
São chamados por controllers ou outras Apps (REST);
●
Um anel ao redor do Domínio;
●
Controlam transações;
●
Controla segurança, sessão;
●
Usam serviços de infraestrutura (msg, notifica, e-mail).
Ofertado
pela
aplicação

Application Services
class FiscalApplicationService
{
function valida( nfe ) // carrega, valida
function assina( nfe ) // carrega, valida, gera xml, assina, atualiza
function transmite( nfe ) // carrega, valida, transmite, gera mov, atualiza
function geraDanfe( nfe ) // carrega, gera pdf
function cancelaNota( nfe ) // carrega, cancela venda, gera mov, atualiza
}
class DefaultAuthenticationService {
function authenticate ( user, pass ) {
// verifica parametros, exception se vazio.
// instancia a partir do login
// Verifica se está ativo
// compara senhas criptografadas (lib)
// LDAP?
}
}
Não são do
Core Domain
Envolve
Infrastructure Services

●
Abstrai partes técnicas:
– Email, SMS, Telegram, NFSE, CNAB, etc.
●
Facade
– Esconde um subconjunto interno de
bibliotecas para consumo unificado.
●
Gateway
– Disponibiliza um recurso externo para a App.
Ofertado
pela
infraestrutura

class NotasGatewayService
{
function emitir ( empresa, array data)
function cancelar( empresa, chave )
}
class CNABService
{
function geraCobranca( local_cobranca, inicio, fim, [cliente] )
// carrega objetos filtrados, gera ocorrencias
function baixaCobranca( local_cobranca, arquivo )
// carrega arquivo, parse, calcula saldo, baixa conta, atualiza
}
class AmazonServices
{
function sendFile()
function getFile()
}
Gateway externo
SAAS
Biblioteca de classes
Formato específico

Dependency Inversion Principle
●
Como vincular camadas sem forte acoplamento?
●
Controller App Service; App service Dom Service.→ →
●
Evitar acoplamento concreto (hard-coded).
●
Inversão de dependência.
●
É invertida em relação à programação tradicional.
●
Não é determinada diretamente pelo programador.
●
Controle é delegado a infraestrutura de software.
●
Muitas vezes chamada de container.

Dependency Inversion Principle
<?php
require 'vendor/autoload.php';
use UMADICContainer;
$container = new Container();
$container->set('nfse-gateway', function(Container $c): string {
return NotasGatewayService::class;
});
// FiscalApplicationService...
$gateway = $container->get('nfse-gateway');
$gateway::emitir();
Define
Consome

Bounded Contexts
●
Um domínio deve ter uma fronteira.
●
Seria bom fazer um grande sistema para tudo?
●
Não separar subdomínios faz tudo ficar dependente.
●
É preciso separar logicamente os subdomínios.
●
Ex: Lançamento, pode ter diferentes significados.
– Ex: Produto, Bem, item de consumo.
●
Permissão não precisa estar amarrada com o negócio
●
Um ERP tem módulos (subdomínios):
– Inventário, compras, recebíveis

Bounded Contexts
●
Para Vernon, mundo ideal 1=1 (subdomínio=BC).
●
Existem situações indesejáveis, softwares legados.
●
Quando os contextos se comunicam...
– Interfaces são bem vindas.
– Entidades são um começo.
– Serviços ajudam.
– API’s isolam mais ainda.
●
Permite equipes separadas para cada BC.
Imagine um
módulo consultando
a tabela de
outro

REST integration
class UserRestService
{
function inRole( $param ) {
UserService::checkInGroup( $param['user'], $param['group'] );
}
class ContaReceberRestService
{
function geraContas($param)
{
// abre transacao
$venda = Venda::find($param['venda_id'];
$politica = Politica::find($param['politica_id']);
ContaReceberService::geraContas($venda, $param['parcelas'],
politica_cobranca)
// fecha transacao
}
}

Arquitetura

Obrigado
●
pablo.blog.br
●
adianti.com.br
●
@pablodalloglio
●
@adiantisolution

Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude

Mais conteúdo relacionado

Mais procurados (19)

Semelhante a Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude (20)

Último (7)

Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude