Você já sentiu que conforme seu projeto Laravel cresce, as coisas começam a ficar um pouco fora de controle? Os controladores ficam inchados, os modelos começam a fazer muito e, de repente, sua base de código é como aquela gaveta que você deseja organizar há meses. É aqui que o Domain-Driven Design (DDD) pode intervir e tornar sua vida mais fácil.

DDD é uma forma de projetar seu aplicativo para que sua estrutura se alinhe estreitamente com o problema que você está resolvendo no mundo real. Isso ajuda a tornar seu código mais limpo, mais escalável e mais fácil de gerenciar à medida que seu projeto cresce.

Neste guia, orientaremos você nos fundamentos do DDD no Laravel, explicaremos como você pode implementá-lo e mostraremos alguns exemplos do mundo real ao longo do caminho.

Índice

1. O que é Design Orientado a Domínio (DDD)?
2. Por que usar DDD no Laravel?
3. Os componentes do DDD
   • Entidades
   • Objetos de valor
   • Repositórios
   • Serviços
4. Implementando DDD no Laravel
   • Exemplo 1: Construindo um Sistema de Gerenciamento de Pedidos
   • Exemplo 2: gerenciamento de assinaturas de usuários
5. Prós e contras do DDD no Laravel
6. Considerações Finais

O que é Design Orientado a Domínio (DDD)?

Antes de nos aprofundarmos nos detalhes do Laravel, vamos abordar o que é Domain-Driven Design (DDD). DDD é uma maneira de organizar o código do seu aplicativo, concentrando-se no domínio de negócios – o problema central que seu software está resolvendo.

Em vez de estruturar seu código em torno de conceitos técnicos, como controladores ou modelos, você o estrutura em torno de conceitos do mundo real. Podem ser itens como pedidos, produtos ou clientes, dependendo do que seu aplicativo faz.

Em poucas palavras, o DDD ajuda você a construir um aplicativo que espelha processos do mundo real, tornando o código mais fácil de entender e manter, especialmente à medida que ele cresce.

Por que usar DDD no Laravel?

Se você está familiarizado com o padrão MVC (Model-View-Controller) que o Laravel usa por padrão, você sabe que ele funciona muito bem para a maioria das aplicações. Mas à medida que seu aplicativo é dimensionado, o padrão MVC pode levar a uma confusão de códigos interdependentes. Domain-Driven Design resolve esse problema, tornando seu aplicativo mais fácil de estender e manter ao longo do tempo.

DDD também separa a lógica de negócios do código de infraestrutura. Isso significa que a lógica do seu aplicativo não estará vinculada a coisas como bancos de dados ou APIs, facilitando a troca de tecnologias posteriormente.

Os componentes do DDD

Para entender como o DDD funciona, você precisa conhecer seus principais componentes. Vamos decompô-los:

Entidades

Entidades são objetos em seu domínio que possuem uma identidade distinta. Por exemplo, um pedido é uma entidade porque cada pedido é único.

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

Objetos de valor

Um Objeto de Valor é um objeto que não possui identidade, mas representa um conceito. Um objeto Money, por exemplo, representa um valor, mas não precisa de um ID exclusivo.

// app/Domain/Order/Money.php
class Money {
    private $amount;
    private $currency;

    public function __construct($amount, $currency) {
        $this->amount = $amount;
        $this->currency = $currency;
    }

    public function getFormatted() {
        return "{$this->amount} {$this->currency}";
    }
}

Repositórios

Um Repositório lida com a busca e persistência de objetos de domínio como entidades. Em vez de seus objetos de domínio interagirem diretamente com o banco de dados, os repositórios gerenciam o acesso aos dados.

// app/Domain/Order/OrderRepositoryInterface.php
interface OrderRepositoryInterface {
    public function findById($id): ?Order;
    public function save(Order $order): void;
}

// app/Infrastructure/Order/EloquentOrderRepository.php
class EloquentOrderRepository implements OrderRepositoryInterface {
    public function findById($id): ?Order {
        // Fetch order using Eloquent
    }

    public function save(Order $order): void {
        // Save order using Eloquent
    }
}

Serviços

Um Serviço lida com a lógica de negócios, como criar um pedido ou processar um pagamento. Em vez de colocar essa lógica em seus controladores, você a encapsula em serviços.

// app/Domain/Order/CreateOrderService.php
class CreateOrderService {
    public function execute($data) {
        $order = new Order($data['id'], $data['status']);
        // Business logic for creating an order
    }
}

Implementando DDD no Laravel

Agora que você entende os componentes principais, vamos ver como podemos implementar DDD no Laravel com alguns exemplos do mundo real.

Exemplo 1: Construindo um Sistema de Gerenciamento de Pedidos

Digamos que você esteja construindo um Sistema de gerenciamento de pedidos para um site de comércio eletrônico. Veja como o DDD ajudaria você a organizar seu código:

1. Entidades: você teria uma entidade Order para representar cada pedido, com atributos como id e status.
2. Objetos de valor: você pode criar um objeto de valor monetário para representar preços.
3. Repositórios: você criaria um OrderRepository para buscar e armazenar pedidos no banco de dados.
4. Serviços: Um CreateOrderService lidaria com a lógica para criar novos pedidos.

Aqui está um fluxo básico:

// app/Http/Controllers/OrderController.php
class OrderController {
    private $createOrderService;

    public function __construct(CreateOrderService $createOrderService) {
        $this->createOrderService = $createOrderService;
    }

    public function store(Request $request) {
        $this->createOrderService->execute($request->all());
        return response()->json(['message' => 'Order created!']);
    }
}

Exemplo 2: Gerenciando assinaturas de usuários

Imagine que você está gerenciando assinaturas de usuários para uma plataforma SaaS. Usando DDD, você criaria:

• Uma entidade de assinatura para representar a assinatura de cada usuário.
• Um objeto de valor Duração para gerenciar períodos de assinatura.
• Um SubscriptionRepository para lidar com o acesso a dados.
• Um SubscriptionService para lidar com a lógica de negócios, como a renovação de uma assinatura.

Veja como você pode lidar com a renovação de uma assinatura:

// app/Domain/Subscription/RenewSubscriptionService.php
class RenewSubscriptionService {
    private $subscriptionRepository;

    public function __construct(SubscriptionRepositoryInterface $subscriptionRepository) {
        $this->subscriptionRepository = $subscriptionRepository;
    }

    public function renew($subscriptionId) {
        $subscription = $this->subscriptionRepository->findById($subscriptionId);
        $subscription->renew();
        $this->subscriptionRepository->save($subscription);
    }
}

Prós e contras do DDD no Laravel

Prós:

• Melhor organização: o código está bem estruturado em torno do domínio.
• Escalabilidade: Mais fácil de dimensionar e gerenciar aplicativos grandes.
• Manutenção: A lógica de negócios é separada das preocupações de infraestrutura.

Contras:

• Curva de aprendizado: DDD introduz novos conceitos, que podem ser complicados no início.
• Despesas gerais para projetos pequenos: Implementar DDD para projetos pequenos e simples pode parecer um exagero.

Considerações Finais

DDD no Laravel pode parecer assustador, mas quando você começa a pensar em termos de domínios de negócios em vez de camadas técnicas, isso começa a fazer sentido. É tudo uma questão de manter seu código limpo, sustentável e escalonável à medida que seu projeto cresce.

Comece aos poucos. Refatore um recurso em seu aplicativo usando princípios DDD e veja como funciona. Com o tempo, você começará a apreciar a organização e a clareza que ela traz.

Boa sorte e boa codificação!