Quando um Monólito Modular É a Escolha Certa

A arquitetura de software deve seguir as restrições do negócio, do produto e da equipa — não a tendência do momento.

Começar pelo problema real

Os microsserviços podem permitir lançamentos e escalabilidade independentes, mas também introduzem limites de rede, observabilidade distribuída e maior carga operacional.

Antes de dividir um sistema, pergunte:

• As equipas precisam realmente de fazer lançamentos independentes?
• Existem partes do sistema com necessidades de escala muito diferentes?
• Os limites dos domínios já estão compreendidos?
• A organização consegue suportar a complexidade operacional adicional?

Manter limites sem adicionar uma rede

Um monólito modular pode manter as áreas de negócio separadas dentro de uma única aplicação. Módulos claros, interfaces explícitas e testes automatizados preservam esses limites sem exigir infraestrutura distribuída.

final readonly class CreateInvoice
{
    public function __construct(
        private InvoiceRepository $invoices,
    ) {}

    public function execute(CreateInvoiceCommand $command): Invoice
    {
        $invoice = Invoice::create($command->customerId, $command->lines);
        $this->invoices->save($invoice);

        return $invoice;
    }
}

Um ponto de partida útil

Comece com a arquitetura mais simples que proteja os limites importantes. Avance para serviços distribuídos quando a evidência de produção e as necessidades organizacionais justificarem o custo — não antes.