Uma consequência prática: evite “serviços gigantes” que fazem tudo. No monolito bem desenhado,
cada conjunto de funcionalidades concentra regras relacionadas, e o resto do sistema interage por interfaces,
não por conhecimento íntimo.

Monolitos duradouros dependem de domínio estável. Isso significa colocar invariantes
onde elas pertencem: no domínio.

Invariantes são regras que não mudam com “como a requisição chegou”. Elas devem permanecer verdadeiras
independentemente de HTTP, batch, fila, cron ou testes.

• Entidades representam coisas com identidade (ex.: Order).
  Mantenha seus estados consistentes por meio de métodos, não por setters livres.
• Value Objects encapsulam validações e semântica (ex.: Email, Money).
• Casos de uso orquestram, mas não decidem regras complexas: eles chamam o domínio.
• Erros e resultados devem ser explícitos (ex.: falha de validação, conflito de regra, recurso inexistente).

Um sinal de que seu monolito está saudável: ao mudar uma regra de negócio, você altera
principalmente o mesmo lugar no código. Se você precisa “varrer o projeto inteiro”,
seu domínio está diluído.

// Exemplo conceitual (Java/Kotlin-style), adaptável ao seu stack.

// Value Object: garante invariantes na construção
final class Email {
  private final String value;

  Email(String value) {
    if (value == null || !value.contains("@")) {
      throw new IllegalArgumentException("Email inválido");
    }
    this.value = value.toLowerCase();
  }

  String value() { return value; }
}

// Entidade: controla estado e consistência
final class Order {
  enum Status { CREATED, PAID, CANCELED }

  private final String id;
  private Status status;

  Order(String id) {
    this.id = id;
    this.status = Status.CREATED;
  }

  void markAsPaid() {
    if (status != Status.CREATED) {
      throw new IllegalStateException("Pagamento só pode ocorrer em CREATED");
    }
    this.status = Status.PAID;
  }

  Status status() { return status; }
}

// Caso de uso: orquestra, valida e delega regra ao domínio
final class PayOrderUseCase {
  private final OrderRepository repo;

  PayOrderUseCase(OrderRepository repo) {
    this.repo = repo;
  }

  PayOrderResult execute(String orderId, Payment payment) {
    Order order = repo.findById(orderId)
      .orElseThrow(() -> new NotFoundException("Pedido não encontrado"));

    // Regra de negócio aplicada pelo domínio
    order.markAsPaid();

    repo.save(order);
    return new PayOrderResult(orderId, true);
  }
}

Monolito vence quando facilita mudanças. Para isso, você precisa de um ciclo de feedback rápido:
testes bem posicionados, métricas de qualidade e refatorações com baixo risco.

• Piramide de testes orientada a comportamento:
  teste de domínio (rápido e consistente), teste de casos de uso (integração controlada),
  e poucos testes end-to-end (confiança no fluxo).
• Contratos internos: caso de uso retorna tipos claros e erros previsíveis.
  Isso diminui acoplamento entre camada de API e aplicação.
• Strangler interno (sem drama): quando for evoluir um trecho,
  extraia primeiro para uma “nova borda” dentro do mesmo monolito antes de mover qualquer coisa.
• Refatoração com “caracterização”: antes de otimizar arquitetura,
  crie testes que capturam comportamento atual. Depois, refatore.

Um padrão que ajuda muito: tratar o fluxo de mudança como um pipeline. Você adiciona testes,
garante cobertura do domínio, e só então mexe em infraestrutura/persistência. Assim, quando algo quebrar,
você sabe onde procurar.

Em monolitos, a performance e a estabilidade ficam mais previsíveis quando você mede corretamente.
Observabilidade não é “dashboard por dashboard”: é reduzir incerteza em incidentes e otimizações.

• Logs com contexto: inclua identificadores de requisição/correlação, usuário (quando fizer sentido) e
  variáveis de negócio relevantes. Evite logar tudo indiscriminadamente.
• Métricas de latência: acompanhe P50/P95/P99 por rota e por caso de uso, não apenas por serviço.
• Traces para identificar tempos em dependências (DB, chamadas internas, chamadas externas).
• Estratégia de timeouts e retry: retries devem ser decisão consciente do caso de uso, com limites.
  Caso contrário, você amplifica falhas.
• Banco de dados: use índices com intencionalidade e monitore queries lentas.
  No monolito, “um endpoint ruim” costuma ser um problema de domínio/perfil de consulta.

Além disso, mantenha infraestrutura “pluggable” internamente: a API não deve depender de detalhes do ORM,
e o domínio não deve depender de como o dado é armazenado. Isso reduz acoplamento operacional.

// Exemplo conceitual de log com contexto e métricas por caso de uso.
// Adapte ao seu framework/linguagem.

// Entrada: HTTP + correlação
const requestId = ctx.headers["x-request-id"] ?? crypto.randomUUID();

// Métrica de tempo por caso de uso
const timer = metrics.startTimer("usecase_pay_order_latency_ms", { requestId });

// Log com contexto mínimo
logger.info("usecase.payOrder.start", { requestId, orderId });

try {
  const result = payOrderUseCase.execute(orderId, payment);
  logger.info("usecase.payOrder.success", { requestId, orderId, paid: result.paid });
  metrics.increment("usecase_pay_order_success_total", { requestId });
  return http.ok(result);
} catch (e) {
  logger.error("usecase.payOrder.error", {
    requestId,
    orderId,
    errorType: e.name,
    message: e.message
  });
  metrics.increment("usecase_pay_order_error_total", { requestId, errorType: e.name });
  return mapErrorToHttp(e);
} finally {
  timer.stop(); // sempre registra
}