Separação Clara de Camadas: Core, Domain e Infra

Fala Dev! Blz? Asllan aqui… vamos evoluir ainda mais nosso plugin agora com a Separação Clara de Camadas: Core, Domain e Infra!

Separar bem as camadas do seu plugin não é “frescura de programador chato”. É engenharia de verdade.

Neste post, você vai entender como organizar o seu plugin em 3 camadas fundamentais:

• Core → Lógica de negócio que não depende de WordPress.
• Domain → Contratos e regras do seu domínio (entidades, serviços, interfaces).
• Infra → Tudo que é específico do WordPress (hooks, filtros, API REST, banco, etc).

😰 O problema de não separar as camadas

Você já viu plugins onde tudo acontece em uma classe só? Tipo assim:

class MeuPlugin {
  function init() {
    if (isset($_GET['acao'])) {
      $user = get_user_by('id', $_GET['user']);
      // envia email, salva log, atualiza post, etc
    }
  }
}

Esse tipo de código acopla lógica, acesso a dados e regras específicas num balaio só.

Resultado: difícil de testar, difícil de dar manutenção, e impossível de escalar.

✅ O que é essa separação de camadas?

Aqui vai o mapa da mina:

src/
│
├── Core/           <- Lógica isolada (pode ser testada fora do WP)
│   └── Services/
│       └── ValidadorDeCPF.php
│
├── Domain/         <- Regras do domínio (interfaces, contratos, entidades)
│   └── Contracts/
│       └── LoggerInterface.php
│   └── Entities/
│       └── Cliente.php
│
└── Infra/          <- Integrações específicas com o WordPress
    ├── Http/
    │   └── Controllers/
    │       └── ApiController.php
    ├── Repositories/
    │   └── UserRepository.php
    └── WordPress/
        └── Hooks.php

🚀 Como aplicar isso no plugin WP24H

Vamos supor que você tenha um serviço para validar uma assinatura via API.

1. Core → AssinaturaValidator.php

namespace WpArquiteturaExtrema\Core;

class AssinaturaValidator
{
    public function validar(string $token): bool
    {
        // Validação pura, sem WordPress
        return strlen($token) === 32;
    }
}

2. Domain → LoggerInterface.php

namespace WpArquiteturaExtrema\Domain\Contracts;

interface LoggerInterface
{
    public function info(string $message): void;
    public function error(string $message, array $context = []): void;
}

3. Infra → WordPressLogger.php

namespace WpArquiteturaExtrema\Infra;

use WpArquiteturaExtrema\Domain\Contracts\LoggerInterface;

class WordPressLogger implements LoggerInterface
{
    public function info(string $message): void
    {
        error_log("[INFO] $message");
    }

    public function error(string $message, array $context = []): void
    {
        error_log("[ERROR] $message - " . json_encode($context));
    }
}

🤖 Por que isso importa?

• Testar sua lógica sem precisar carregar o WordPress.
• Trocar a implementação de algo sem quebrar o resto.
• Criar comandos WP-CLI, APIs, ou blocos Gutenberg que usam os mesmos serviços.

🔗 Link com os dias anteriores

• No Dia 02/15 falamos sobre serviços e delegação de responsabilidades.
• No Dia 06/15 implementamos comandos WP-CLI profissionais.

Agora você entende como tudo isso se encaixa num plugin robusto, sustentável e escalável.

✍️ Conclusão

Separar seu plugin por camadas não é exagero, é sobrevivência. Plugins bem escritos seguem esse modelo porque:

✔️ São testáveis
✔️ São fáceis de manter
✔️ São preparados para crescer

Agora seu desafio é adaptar nosso plugin, já muito bem estruturado, a essa nova engenharia.