WordPress Extremo: Arquitetura e Engenharia de Plugins
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.
