Design tático do DDD

Conforme descrito na publicação “Design estratégico do DDD”, o DDD pode ser dividido em duas partes: estratégico (“o quê e por quê estamos construindo”) e tático.

O design tático trata de como implementar o modelo de domínio dentro de um contexto delimitado. O objetivo é transformar o conhecimento levantado no design estratégico em código que represente a lógica de negócio preservando consistência, expressividade e manutenibilidade.

Seguindo a sequência, neste artigo abordo os padrões e conceitos do design tático no DDD. O artigo é baseado no livro “Aprendendo Domain-Driven Design” de Vlad Khononov.

Press enter or click to view image in full size

Implementando uma Lógica de Negócio Simples

A lógica de negócio é o núcleo do software. Ela representa as regras, decisões e invariantes que definem porque o sistema existe. Existem diferentes formas de implementar a lógica conforme a complexidade do domínio.

Script de Transação

O padrão Script de Transação organiza a lógica de negócio de forma procedural. Cada procedimento implementa uma operação específica do sistema, exposta por meio de uma interface pública.

É o padrão mais comum utilizado na maioria dos sistemas, essas operações públicas atuam como limites de encapsulamento, cada uma coordena validações, acessos a dados e atualizações necessárias para executar uma ação do negócio.

Características principais:

• Cada operação deve ser atômica, ou é concluída com sucesso ou falha completamente.
• O fluxo é explícito e sequencial, facilitando o entendimento em domínios simples.
• A consistência é garantida dentro da própria transação, geralmente alinhada a uma única operação do sistema.

Esse padrão é adequado quando a complexidade do domínio é baixa e as regras de negócio são diretas.

class OrderPaymentService {

public void pay(Order order) {
if (!”ABERTO”.equals(order.status)) {
throw new IllegalStateException(“Pedido não pode ser pago”);
}

order.status = “PAGO”;
System.out.println(“Pedido “ + order.id + “ pago com sucesso”);

}
}

• Não existe comportamento no objeto Order
• O objeto apenas carrega dados
• O serviço manda no fluxo
• A regra está explícita e centralizada
• Não há polimorfismo, invariantes distribuídas ou agregados

Registro Ativo

O padrão Registro Ativo junta dados e comportamento em um único objeto que representa uma tabela ou registro do banco de dados.

Cada instância encapsula tanto o estado quanto operações de salvar, atualizar, remover, regras simples de negócio, etc. É uma abordagem prática para domínios simples, mas pode se tornar difícil de manter conforme aumenta a complexidade da lógica de negócio.

class Order {
Long id;
String status;

Order(Long id, String status) {
this.id = id;
this.status = status;
}

public void pay() {
if (!”ABERTO”.equals(status)) {
throw new IllegalStateException(“Pedido não pode ser pago”);
}
status = “PAGO”;
save();
}

public void save() {
System.out.println(“Salvando pedido “ + id + “ com status “ + status);
}

public void delete() {
System.out.println(“Removendo pedido “ + id);
}
}

• O objeto Order representa diretamente a tabela Pedido
• Ele contém os dados
• Ele contém a regra de negócio
• Ele sabe se salvar e se remover
• Não existe serviço de aplicação

Lidando com Lógica de Negócio Complexa

Quando o domínio tem um nível mais alto de complexidade, padrões procedurais deixam de ser suficientes. Nesse cenário é onde entra o Modelo de Domínio.

Modelo de Domínio (Domain model)

O Modelo de Domínio é um modelo orientado a objetos que encapsula dados e comportamentos do domínio de negócio. Ele é composto pelos principais padrões táticos do DDD:

• Agregados
• Entidades
• Objetos de Valor
• Eventos de Domínio
• Serviços de Domínio

Ele deve ser o mais expressivo possível para capturar regras, invariantes e comportamentos essenciais do negócio. Isso sem se preocupar com características técnicas como persistência, mensageria ou infraestrutura.

Ao focar na lógica de negócio, o modelo passa a refletir diretamente a Linguagem Ubíqua do contexto delimitado, tornando o código mais fácil, expressivo e alinhado com o entendimento dos especialistas do domínio.

Entidades

Entidades representam conceitos do domínio que possuem identidade própria e ciclo de vida. Duas entidades podem ter os mesmos atributos, mas ainda serem diferentes por conta de sua identidade.

Características principais:

• São identificadas por um identificador único.
• Seus atributos podem mudar ao longo do tempo sem que a identidade seja alterada.
• Encapsulam comportamento e regras relacionadas ao seu ciclo de vida.

Enquanto objetos de valor representam descrições imutáveis, entidades representam coisas que evoluem no domínio. A diferença entre entidades e objetos de valor é importante para evitar modelos complexos ou inconsistentes.

class Order {
private final UUID id;
private OrderStatus status;
private LocalDateTime paidAt;

public Order(UUID id) {
this.id = id;
this.status = OrderStatus.CREATED;
}

/_ IDENTIDADE _/
public UUID getId() {
return id;
}

/_ COMPORTAMENTO DE DOMÍNIO _/
public void pay() {
if (status != OrderStatus.CREATED) {
throw new IllegalStateException(
“Pedido só pode ser pago se estiver no estado CREATED”
);
}

this.status = OrderStatus.PAID;
this.paidAt = LocalDateTime.now();

}

public void cancel() {
if (status == OrderStatus.PAID) {
throw new IllegalStateException(
“Pedido pago não pode ser cancelado”
);
}

this.status = OrderStatus.CANCELLED;

}

/_ CONSULTAS DE ESTADO (SEM REGRA) _/
public boolean isPaid() {
return status == OrderStatus.PAID;
}
}

• O id define a identidade, não os atributos
• Dois pedidos podem ter os mesmos dados, mas não são o mesmo pedido
• O estado muda ao longo do tempo
• As regras estão dentro da entidade
• O estado só muda por meio de métodos explícitos

Objeto de Valor

Ao contrário da entidade, objetos de valor representam conceitos do domínio que não possuem identidade, sendo definidos por seus atributos.

O uso excessivo de tipos primitivos (strings, inteiros, decimais) para representar conceitos do domínio é conhecido como Primitive Obsession. Objetos de valor resolvem esse problema ao encapsular significado, validações e comportamento em tipos explícitos do domínio.

Características principais:

• São imutáveis: qualquer alteração resulta em uma nova instância.
• São comparados por valor, não por identidade.
• Ajudam a expressar regras de negócio de forma clara e segura.

public final class Money {
private final BigDecimal amount;
private final String currency;

public Money(BigDecimal amount, String currency) {
if (amount == null || amount.compareTo(BigDecimal.ZERO) < 0) {
throw new IllegalArgumentException(“Valor monetário inválido”);
}
if (currency == null || currency.isBlank()) {
throw new IllegalArgumentException(“Moeda inválida”);
}
this.amount = amount;
this.currency = currency;
}

/_ COMPORTAMENTO DE DOMÍNIO _/
public Money add(Money other) {
if (!this.currency.equals(other.currency)) {
throw new IllegalArgumentException(“Moedas diferentes”);
}
return new Money(
this.amount.add(other.amount),
this.currency
);
}

/_ IGUALDADE POR VALOR _/
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof Money)) return false;
Money money = (Money) o;
return amount.compareTo(money.amount) == 0 &&
currency.equals(money.currency);
}

@Override
public int hashCode() {
return Objects.hash(amount.stripTrailingZeros(), currency);
}
}

• Não existe id
• Dois Money(100, “BRL”) são a mesma coisa
• Não faz sentido “alterar” um Money
• Toda mudança gera uma nova instância
• As regras vivem dentro do tipo, não espalhadas pelo sistema

Agregados

Um Agregado é um cluster de entidades e objetos de valor tratado como uma única unidade de consistência. Ele define uma fronteira entre o que está dentro do agregado e o mundo externo.

Principais conceitos:

• O agregado é a fronteira de consistência: todas as invariantes devem ser garantidas dentro de seus limites.
• Apenas a raiz do agregado pode ser acessada diretamente por outros objetos.
• Operações de modificação devem acontecer por meio de métodos públicos da raiz do agregado, muitas vezes recebendo comandos que representam intenções do negócio.

Outros aspectos relevantes:

• O agregado define o limite transacional: uma transação não deve atravessar múltiplos agregados.
• Um agregado pode conter uma hierarquia de entidades, mas nem toda entidade é um agregado.
• Entidades e objetos de valor coexistem dentro do agregado, cada um com responsabilidades bem definidas.

Agregados podem notificar eventos de domínio para sinalizar mudanças no estado do negócio. Esses eventos reforçam a atomicidade das operações e facilitam integrações e reações assíncronas.

A modelagem de agregados deve refletir diretamente a Linguagem Ubíqua, utilizando termos e comportamentos reconhecíveis pelos especialistas do domínio.

/**

• AGREGADO
• Raiz do agregado: Order
• Fronteira de consistência: Pedido e seus itens
  /
  class Order {
  / IDENTIDADE DA RAIZ DO AGREGADO */
  private final UUID id;

/_ ESTADO DO AGREGADO _/
private OrderStatus status;
private final List items;
private Money total;

public Order(UUID id) {
this.id = id;
this.status = OrderStatus.CREATED;
this.items = new ArrayList<>();
this.total = Money.zero();
}

/_ RAIZ DO AGREGADO _/
public UUID getId() {
return id;
}

public OrderStatus getStatus() {
return status;
}

/**

• Operação de negócio exposta pelo agregado.
• Garante as invariantes internas.
  */
  public void addItem(ProductId productId, int quantity, Money unitPrice) {
  ensureOrderIsOpen();
  ensureValidQuantity(quantity); OrderItem item = new OrderItem(productId, quantity, unitPrice);
  items.add(item); recalculateTotal();
  }

public void confirm() {
ensureOrderIsOpen();

if (items.isEmpty()) {
  throw new IllegalStateException(“Pedido não pode ser confirmado sem itens”);
}

this.status = OrderStatus.CONFIRMED;

}

/_ INVARIANTES DO AGREGADO _/
private void ensureOrderIsOpen() {
if (status != OrderStatus.CREATED) {
throw new IllegalStateException(
“Pedido confirmado não pode ser alterado”
);
}
}

private void ensureValidQuantity(int quantity) {
if (quantity <= 0) {
throw new IllegalArgumentException(“Quantidade inválida”);
}
}

private void recalculateTotal() {
this.total = items.stream()
.map(OrderItem::subtotal)
.reduce(Money.zero(), Money::add);
}

/_ CONSULTAS (SEM MODIFICAÇÃO) _/
public List getItems() {
return Collections.unmodifiableList(items);
}

public Money getTotal() {
return total;
}
}

• Order é a raiz do agregado
• Tudo passa por Order
• OrderItem não pode ser modificado externamente
• As invariantes estão centralizadas
• O agregado define o limite transacional
• Objetos de valor (Money, ProductId) reforçam o modelo

Eventos de Domínio

Eventos de Domínio representam fatos que ocorreram no domínio de negócio. Eles descrevem mudanças de estado nos agregados e fazem parte da essência do modelo, servindo para muito mais do que apenas integrar sistemas tecnicamente.

Características principais:

• São imutáveis.
• Expressam algo que aconteceu no passado.
• Utilizam a terminologia da Linguagem Ubíqua.

Eventos de domínio permitem:

• Comunicação desacoplada entre partes do sistema.
• Integração entre contextos delimitados.
• Implementação de fluxos reativos e assíncronos.

Eles também reforçam a atomicidade das operações do agregado, um evento só é publicado se a mudança de estado for concluída com sucesso.

/**

• EVENTO DE DOMÍNIO
• — Representa um fato que já aconteceu
• — É imutável
• — Usa linguagem do domínio
  */
  public final class OrderConfirmed {
  private final UUID orderId;
  private final Instant occurredAt;

public OrderConfirmed(UUID orderId, Instant occurredAt) {
this.orderId = orderId;
this.occurredAt = occurredAt;
}

public UUID getOrderId() {
return orderId;
}

public Instant getOccurredAt() {
return occurredAt;
}
}

/**

• Emissão do Evento pelo Agregado
  */
  public class Order {
  private final UUID id;
  private OrderStatus status; private final List