DEV Community: Victor Lis Bronzo

From "Merge is Deploy" to Release Engineering with GitHub Actions

Victor Lis Bronzo — Tue, 25 Aug 2026 15:30:31 +0000

Have you ever stopped to think about the risk of having a pipeline where any merge into the main branch deploys straight to production without a single safety gate?

For a long time, our workflow here was that classic setup almost every developer has used at some point: merge on main triggering an SSH script with git pull and pm2 restart

It worked for day-to-day tasks, but it gave a false sense of stability lol

The reality check hit when I found a critical blind spot in the automation: remote SSH scripts were running without strict error handling. In other words, if a git pull caused a conflict or a database migration failed halfway through, the script simply ignored the failure, ran to the end, and GitHub Actions marked the pipeline as green

The absolute worst-case scenario for monitoring: the pipeline reported that everything went smoothly, while production was already completely down

On top of that, the execution order was inverted: database migrations were running before the application build. If TypeScript threw a type error right after, the database schema had already advanced while the new code never booted. And since Prisma has no native down migrations, rolling back meant a high-risk manual intervention

I decided to stop everything and redesign our delivery pipeline from scratch, starting from one clear premise: a tag is a release, a merge is not

Today, nothing touches the production server without an annotated SemVer tag, going through 6 tightly coupled stages:

Strict tag validation: only accepts annotated tags matching vX.Y.Z, ensuring author, timestamp, and audit trail for every single release
Quality gates across PR and Release: automated tests with Vitest, strict typechecking, builds, and migration validation against a clean database via workflow_call
Decoupled backups: an independent daily scheduled routine combined with a mandatory safety snapshot right before touching production
Real migration dry-run: the most valuable gate, where the pipeline restores the latest production dump into an ephemeral scratch database directly inside the VPS, times the migration run, and checks for schema drift before touching the live database
Deterministic deploy: direct checkout on the immutable tag ref, building before running migrations, and concurrency locks to eliminate simultaneous deploy races
Smoke tests: active HTTP health checks and PM2 process scans to verify no service is looping in an error state

The operational impact has been huge: we gained real predictability on migrations, complete traceability for every version, and the confidence that a green pipeline actually means a healthy system in production

For anyone also managing Node and TypeScript applications on VPS or dedicated servers who wants to eliminate blind deploys, I packaged this entire architecture into an open and modular GitHub Actions template

I made the repository public for anyone who wants to use it as a foundation: https://github.com/victor-lis-bronzo/tag-release-template

How do you usually handle deployment gates and database migrations in your stack?

De "Merge é Deploy" para Release Engineering com GitHub Actions

Victor Lis Bronzo — Tue, 25 Aug 2026 15:09:20 +0000

Você já parou pra pensar no risco de manter uma esteira onde qualquer merge na branch principal vai direto pra produção sem nenhum gate de segurança?

Por muito tempo, o nosso fluxo aqui era aquele clássico script que quase todo mundo já usou na vida: merge na main disparando SSH com git pull e pm2 restart

Funcionava no dia a dia, mas era aquela falsa sensação de estabilidade kkkk

A ficha caiu de verdade quando encontrei um ponto cego crítico na automação: os scripts remotos rodavam sem tratamento estrito de erro. Ou seja, se um git pull gerasse conflito ou uma migração de banco falhasse no meio do processo, o script ignorava o erro, executava até o final e o GitHub Actions marcava o pipeline como sucesso

O pior cenário para quem monitora: a esteira reportava que tudo tinha corrido bem, enquanto a aplicação em produção já estava fora do ar

Além disso, a ordem de execução estava invertida: a migração de banco rodava antes do build da aplicação. Se o TypeScript acusasse um erro de tipagem logo depois, o banco já tinha sido alterado e o código novo nem subia. Como o Prisma não possui down migrations nativas, reverter o estado virava uma intervenção manual de alto risco

Decidi parar e redesenhar toda a nossa arquitetura de entrega do zero, partindo de uma premissa clara: tag é release, merge não é

Hoje, nada toca o servidor sem uma tag SemVer anotada, atravessando 6 estágios encadeados:

Validação estrita da tag: só aceita tag anotada no padrão vX.Y.Z, garantindo autor, data e o registro auditável de cada release
Gates de qualidade em PR e Release: testes automatizados com Vitest, typecheck rigoroso, build e validação de migrações em banco limpo via workflow_call
Backup desacoplado: rotina diária agendada somada a um snapshot obrigatório antes de qualquer alteração de infraestrutura
Ensaio real de migração: o gate de maior valor, onde o pipeline restaura o dump de produção num banco descartável dentro da própria VPS, executa a migração cronometrada e checa drift de schema antes de tocar a base oficial
Deploy determinístico: checkout direto na tag imutável, build antes da migração e trava de concorrência pra evitar deploys simultâneos
Smoke tests: validação ativa das portas HTTP e varredura de processos no PM2 pra garantir que nada entrou em loop de erro

O impacto dessa mudança na operação é brutal: conquistamos previsibilidade real nas migrações, rastreabilidade de cada versão e a certeza de que pipeline verde significa sistema íntegro no ar

Pra quem também gerencia aplicações Node e TypeScript em VPS ou servidores dedicados e quer sair do deploy cego, estruturei toda essa arquitetura em um template modular de GitHub Actions

Deixei o repositório aberto pra quem quiser usar de base nos seus projetos: https://github.com/victor-lis-bronzo/tag-release-template

Como vocês costumam desenhar os gates de deploy e migração de banco por aí?

DEPENDENCY INVERSION PRINCIPLE

Victor Lis Bronzo — Thu, 20 Aug 2026 13:17:44 +0000

High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).

In practice, your business rule shouldn't know if you use MySQL, Stripe, or AWS. It should depend only on a contract (Interface) that says WHAT needs to be done, and not HOW it will be done.

RIGID IMPLEMENTATION

The most common mistake on a daily basis is calling a new ExternalTool() directly inside your use case.

When you do this, your code depends on the tool.

If the tool is discontinued or the API changes, you will have to open the "heart" of your system to fix it.

A BAD EXAMPLE

The business class is tightly coupled to the email provider SendGrid. This is a bad practice.

Code Example:

import { SendGridProvider } from 'sendgrid-sdk';

// BAD: The service instantiates the tool directly.
class RegisterUserUseCase {
  private mailProvider: SendGridProvider;

  constructor() {
    // Tight coupling!
    this.mailProvider = new SendGridProvider('API_KEY');
  }

  public async execute(email: string): Promise<void> {
    // ...complex business logic...

    // If SendGrid changes or goes down, this class breaks.
    await this.mailProvider.sendEmail(email, "Welcome!");
  }
}

TURNING THE TABLES

The solution is not to depend on the concrete class SendGridProvider, but rather to create a generic interface within our own domain.

Our service now receives this dependency ready via the constructor (Dependency Injection).

The most interesting part is that our application doesn't need to know exactly who is under the hood, whether it's Resend, EmailJS, or another, it just follows the template.

A GOOD EXAMPLE

The service now depends only on the contract. The infrastructure must obey.

Code Example:

// GOOD: The contract belongs to OUR application.
interface IMailProvider {
  send(to: string, message: string): Promise<void>;
}

class RegisterUserUseCase {
  // We receive the abstraction from the outside (Dependency Injection)
  constructor(private mailProvider: IMailProvider) {}

  public async execute(email: string): Promise<void> {
    // ...complex business logic...

    // The service has no idea which tool is sending it
    await this.mailProvider.send(email, "Welcome!");
  }
}

THE POWER OF INVERSION

The biggest advantage of DIP is Modularity.

If tomorrow your client asks to swap SendGrid for AWS SES, you just create a new implementation of the interface. The RegisterUserUseCase class suffers no changes.

Besides that, Unit Tests become absurdly easier, because you can inject a fake email Mock without needing to trigger real emails.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Were you already applying Dependency Injection before knowing it was the basis of DIP?

PRINCÍPIO DA INVERSÃO DE DEPENDÊNCIA

Victor Lis Bronzo — Thu, 20 Aug 2026 13:11:26 +0000

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações (interfaces).

Na prática, a sua regra de negócio não deve saber se você usa MySQL, Stripe ou AWS. Ela deve depender apenas de um contrato (Interface) que diz O QUE precisa ser feito, e não COMO será feito.

IMPLEMENTAÇÃO ENGESSADA

O erro mais comum no dia a dia é dar um new FerramentaExterna() direto dentro do seu caso de uso.

Quando você faz isso, seu código depende da ferramenta.

Se a ferramenta for descontinuada ou a API mudar, você terá que abrir o "coração" do seu sistema para consertar.

UM MAU EXEMPLO

A classe de negócio fortemente acoplada ao provedor de e-mail SendGrid. Isso é uma má prática.

Exemplo de Código:

import { SendGridProvider } from 'sendgrid-sdk';

// RUIM: O serviço instancia a ferramenta diretamente.
class RegisterUserUseCase {
  private mailProvider: SendGridProvider;

  constructor() {
    // Forte acoplamento!
    this.mailProvider = new SendGridProvider('API_KEY');
  }

  public async execute(email: string): Promise<void> {
    // ...lógica complexa de negócio...

    // Se o SendGrid mudar ou cair, essa classe quebra.
    await this.mailProvider.sendEmail(email, "Bem-vindo!");
  }
}

INVERTENDO O JOGO

A solução é não depender da classe concreta SendGridProvider, mas sim criar uma interface genérica dentro do nosso próprio domínio.

O nosso serviço passa a receber essa dependência pronta pelo construtor (Injeção de Dependência).

A parte mais interessante é que nossa aplicação não precisa saber exatamente quem está por baixo dos panos, seja Resend, EmailJS ou outro, ela apenas segue o molde.

UM BOM EXEMPLO

O serviço agora depende apenas do contrato. A infraestrutura que obedeça.

Exemplo de Código:

// BOM: O contrato pertence à NOSSA aplicação.
interface IMailProvider {
  send(to: string, message: string): Promise<void>;
}

class RegisterUserUseCase {
  // Recebemos a abstração de fora (Injeção de Dependência)
  constructor(private mailProvider: IMailProvider) {}

  public async execute(email: string): Promise<void> {
    // ...lógica complexa de negócio...

    // O serviço não faz ideia de qual ferramenta está enviando
    await this.mailProvider.send(email, "Bem-vindo!");
  }
}

O PODER DA INVERSÃO

A maior vantagem do DIP é a Modularidade.

Se amanhã o seu cliente pedir para trocar o SendGrid pela AWS SES, você só cria uma nova implementação da interface. A classe RegisterUserUseCase não sofre nenhuma alteração.

Além disso, os Testes Unitários ficam absurdamente mais fáceis, pois você pode injetar um Mock de e-mail falso sem precisar fazer disparos reais.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você já aplicava Injeção de Dependência antes de saber que isso era a base do DIP?

INTERFACE SEGREGATION PRINCIPLE

Victor Lis Bronzo — Thu, 20 Aug 2026 13:03:54 +0000

No class should be dependent on methods it doesn't need.

An example would be a "Machine" interface that forces the print(), scan(), and fax() methods. Not every machine has these 3 methods.

So we create the IPrinter, IScanner, and IFax interfaces. Now a machine signs only the contracts it actually needs and fulfills only those.

Code Example (Optional - Illustrating the text):

// ❌ Anti-pattern: Generic interface forcing unused methods
interface IMachine {
  print(): void;
  scan(): void;
  fax(): void;
}

// ✅ SOLID: Segregated and specific interfaces
interface IPrinter { print(): void; }
interface IScanner { scan(): void; }
interface IFax { fax(): void; }

THE DEFINITION

In practice, we can understand ISP as the concept that a class should never depend on methods it doesn't use.

The interface must be reusable in several cases, so a rigid interface with excessive methods hinders this process.

When a class signs a giant contract, it is forced to implement methods that make no sense for its context, polluting the code and generating unnecessary coupling.

A BAD EXAMPLE

Context: A blog system where every user signs the same contract.

Here we violate some of the concepts I mentioned.

Code Example:

// BAD: Fat interface. Forces unnecessary behaviors.
interface IUserActions {
  readPost(): void;
  writePost(): void;
  banUser(): void; // A regular user shouldn't see this!
}

class StandardUser implements IUserActions {
  public readPost(): void { console.log("Reading..."); }
  public writePost(): void { console.log("Writing..."); }

  // ERROR: The regular user is forced to have this method
  public banUser(): void {
    throw new Error("Access Denied: You are not an administrator.");
  }
}

DIVIDE AND CONQUER

The solution from the point of view of ISP is clear: break this huge interface into small, well-scoped contracts.

When more than one contract is needed, a new contract can be built with that specific combination, or the subscriber itself can assume more than one contract at a time (depending on the language).

A GOOD EXAMPLE

Same context, but with much better defined scopes.

As can be seen, only what is necessary is signed.

Code Example:

// GOOD: Small and specific interfaces.
interface IReader { readPost(): void; }
interface IWriter { writePost(): void; }
interface IAdmin { banUser(): void; }

// The regular user implements only what they actually do
class StandardUser implements IReader, IWriter {
  public readPost(): void { console.log("Reading..."); }
  public writePost(): void { console.log("Writing..."); }
}

// The Admin signs all contracts
class AdminUser implements IReader, IWriter, IAdmin {
  public readPost(): void { console.log("Reading..."); }
  public writePost(): void { console.log("Writing..."); }
  public banUser(): void { console.log("User banned!"); }
}

IN THE LONG RUN

Segregating interfaces leaves your code highly modular. If tomorrow the banning rules of an IAdmin change, the StandardUser class will not need to be touched or recompiled.

Your system is then built like Lego blocks, fitting together only the pieces (contracts) that make sense for that structure.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Do you have the habit of creating several small interfaces or do you end up creating a single one for everything?

PRINCÍPIO DA SEGREGAÇÃO DE INTERFACES

Victor Lis Bronzo — Thu, 20 Aug 2026 13:03:04 +0000

Nenhuma classe deve ser dependente de métodos que não precisa.

Um exemplo seria uma interface “Máquina”, que força os métodos print( ), scan( ) e fax( ). Nem toda máquina tem esses 3 métodos.

Então criamos as interfaces IPrinter, IScanner e IFax. Agora uma máquina assina apenas os contratos que realmente precisa e cumpre apenas esses.

Exemplo de Código (Opcional - Ilustrando o texto):

// ❌ Anti-pattern: Interface genérica forçando métodos não utilizados
interface IMaquina {
  print(): void;
  scan(): void;
  fax(): void;
}

// ✅ SOLID: Interfaces segregadas e específicas
interface IPrinter { print(): void; }
interface IScanner { scan(): void; }
interface IFax { fax(): void; }

A DEFINIÇÃO

Na prática, podemos entender o ISP como o conceito de que uma classe nunca deve depender de métodos que não utiliza.

A interface deve ser reutilizável em vários casos, logo uma interface engessada e com métodos em excesso atrapalha nesse processo.

Quando uma classe assina um contrato gigante, ela é obrigada a implementar métodos que não fazem sentido para o contexto dela, sujando o código e gerando acoplamento desnecessário.

UM MAU EXEMPLO

Contexto: Um sistema de blog onde todo user assina o mesmo contrato.

Aqui ferimos alguns conceitos que citei.

Exemplo de Código:

// RUIM: Interface obesa. Força comportamentos desnecessários.
interface IUserActions {
  readPost(): void;
  writePost(): void;
  banUser(): void; // Usuário comum não deveria ver isso!
}

class StandardUser implements IUserActions {
  public readPost(): void { console.log("Lendo..."); }
  public writePost(): void { console.log("Escrevendo..."); }

  // ERRO: O usuário comum é forçado a ter esse método
  public banUser(): void {
    throw new Error("Acesso Negado: Você não é administrador.");
  }
}

DIVIDIR PARA CONQUISTAR

A solução no ponto de vista do ISP é clara, quebrar essa interface enorme em pequenos contratos bem escopados.

Quando for necessário mais de um contrato, pode ser construído um novo contrato com essa combinação específica ou o próprio assinante assumir mais de um contrato por vez (a depender da linguagem).

UM BOM EXEMPLO

Mesmo contexto, mas com escopos bem mais definidos.

Como é possível observar, apenas o necessário é assinado.

Exemplo de Código:

// BOM: Interfaces pequenas e específicas.
interface IReader { readPost(): void; }
interface IWriter { writePost(): void; }
interface IAdmin { banUser(): void; }

// O usuário comum implementa apenas o que ele realmente faz
class StandardUser implements IReader, IWriter {
  public readPost(): void { console.log("Lendo..."); }
  public writePost(): void { console.log("Escrevendo..."); }
}

// O Admin assina todos os contratos
class AdminUser implements IReader, IWriter, IAdmin {
  public readPost(): void { console.log("Lendo..."); }
  public writePost(): void { console.log("Escrevendo..."); }
  public banUser(): void { console.log("Usuário banido!"); }
}

A LONGO PRAZO

Segregar interfaces deixa o seu código altamente modular. Se amanhã as regras de banimento de um IAdmin mudarem, a classe StandardUser não precisará ser tocada ou recompilada.

O seu sistema passa a ser construído como blocos de Lego, encaixando apenas as peças (contratos) que fazem sentido para aquela estrutura.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você tem o costume de criar várias interfaces pequenas ou acaba criando uma só para tudo?

LISKOV SUBSTITUTION PRINCIPLE

Victor Lis Bronzo — Thu, 20 Aug 2026 12:56:41 +0000

A parent class must be able to be substituted by its child classes without breaking the application.

In practice, this helps to organize the idea of inheritance, as it prevents us from extending a parent class only to later remove an already implemented method or do a “throw new Error(‘Not implemented’)”.

Making us much more careful during planning.

THE BIGGEST SYMPTOM OF ERROR

Unfortunately, it is a symptom that appears late, but it is exactly when we are going to make a new implementation.

You realize you violated Liskov when you are going to build a class or subclass and need to purposely throw an error in the implementation of a method.

Exactly because that method shouldn't be there, but it is.

A BAD EXAMPLE

For example, in a delivery system.

In this case, the “Delivery” class should be the parent/base for the other implementations.

But the ‘MotoboyDelivery’ class breaks this.

Code Example:

// BAD: The subclass breaks the parent class contract.
class Delivery {
  public calculateShipping(): number {
    return 15.0;
  }

  public getTrackingCode(): string {
    return "TRK123456789";
  }
}

class MotoboyDelivery extends Delivery {
  public calculateShipping(): number {
    return 8.0;
  }

  // ERROR! There is no tracking code.
  public getTrackingCode(): string {
    throw new Error("Motoboys do not have a tracking code.");
  }
}

THE SOLUTION

For those who do not yet know the 'Liskov Substitution Principle', it might seem that fitting in a sequence of 'if's is the solution.

But in reality, the ideal path is to rethink how this abstraction is built.

A good guiding principle is to think that a child class must always be able to take the place of the parent, without breaking the application.

A GOOD EXAMPLE

Still in the delivery system.

‘Delivery’ now has ‘TrackableDelivery’ in the middle of the way.

With this, each “leaf”/edge of the application inherits what makes the most sense and nothing is broken.

Code Example:

interface Delivery {
  calculateShipping(): number;
}

interface TrackableDelivery extends Delivery {
  getTrackingCode(): string;
}

class CorreiosDelivery implements TrackableDelivery {
  public calculateShipping(): number {
    return 15.0;
  }

  public getTrackingCode(): string {
    return "BR987654321X";
  }
}

class MotoboyDelivery implements Delivery {
  public calculateShipping(): number {
    return 8.0;
  }
}

CONCLUSION

Respecting Liskov guarantees predictability.

Whoever calls your method blindly trusts that the contract will be fulfilled, regardless of the class that is passed under the hood.

This brings more security during the implementation of new features or even in the maintenance of old ones.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
And have you ever come across a method violating Liskov in any application?

PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV

Victor Lis Bronzo — Thu, 20 Aug 2026 12:53:54 +0000

Uma classe mãe deve ser capaz de ser substituída pelas suas classes filhas sem que a aplicação quebre.

Isso na prática ajuda a organizar a ideia de herança, já que nos faz evitar estender uma classe mãe, apenas para depois remover um método já implementado ou fazer um “throw new Error(‘Not implemented’)”.

Fazendo com que tenhamos mais cuidado no planejamento.

O MAIOR SINTOMA DE ERRO

Infelizmente é um sintoma que aparece de forma tardia, mas é justamente quando vamos fazer uma nova implementação.

Você percebe que feriu o Liskov quando você vai construir uma classe ou subclasse e precisa lançar um erro proposital na implementação de um método.

Justamente porque aquele método não deveria estar ali, mas está.

UM EXEMPLO RUIM

Por exemplo em um sistema de entregas.

Nesse caso a classe “Delivery” deveria ser a mãe/base para as demais implementações.

Mas a classe ‘MotoboyDelivery’ quebra isso.

Exemplo de Código:

// RUIM: A subclasse quebra o contrato da classe mãe.
class Delivery {
  public calculateShipping(): number {
    return 15.0;
  }

  public getTrackingCode(): string {
    return "TRK123456789";
  }
}

class MotoboyDelivery extends Delivery {
  public calculateShipping(): number {
    return 8.0;
  }

  // ERRO! Não tem código de rastreio.
  public getTrackingCode(): string {
    throw new Error("Motoboys não possuem código.");
  }
}

A SOLUÇÃO

Para quem ainda não conhece o 'Liskov Substitution Principle', pode parecer que encaixar uma sequência de ifs é a solução.

Mas na verdade o caminho ideal é repensar como essa abstração é construída.

Um bom norte é pensar que uma classe filha sempre deve ser capaz de substituir o lugar da mãe, sem quebrar a aplicação.

UM EXEMPLO BOM

Ainda no sistema de entregas.

‘Delivery’ agora tem no meio do caminho ‘TrackableDelivery’.

Com isso, cada “folha”/ponta da aplicação herda quem faz mais sentido e nada é quebrado.

Exemplo de Código:

interface Delivery {
  calculateShipping(): number;
}

interface TrackableDelivery extends Delivery {
  getTrackingCode(): string;
}

class CorreiosDelivery implements TrackableDelivery {
  public calculateShipping(): number {
    return 15.0;
  }

  public getTrackingCode(): string {
    return "BR987654321X";
  }
}

class MotoboyDelivery implements Delivery {
  public calculateShipping(): number {
    return 8.0;
  }
}

CONCLUSÃO

Respeitar o Liskov garante previsibilidade.

Quem chamar o seu método confia cegamente que o contrato será cumprido, independente da classe que for passada por debaixo dos panos.

Isso traz mais segurança durante a implementação de novas features ou mesmo na sustentação das antigas.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
E você já se deparou com um método ferindo Liskov em alguma aplicação?

OPEN - CLOSED PRINCIPLE

Victor Lis Bronzo — Tue, 14 Jul 2026 23:56:10 +0000

OPEN - CLOSED PRINCIPLE

The integral parts of a code should be open for extension and closed for modification.

The idea is to avoid relying on conditional checks using if-else, ternary operators, and switch.

When a new requirement arrives, you add the behavior by creating something new, without modifying the old code.

TO BE FAIR

The idea of not using conditional operators is a result of correctly applying OCP, not the focus itself.

This is because in order to not depend on these operators, excellence in applying polymorphism and abstraction is necessary.

With this, it becomes possible to couple new implementations without rewriting the already existing code.

BAD EXAMPLE

Every new payment method will cause an edit here. It makes new implementations difficult and puts the old ones at risk.

Code Example:

// BAD: Tight coupling. The class needs to be modified for each new rule.
class PaymentProcessor {
  public process(amount: number, method: 'CREDIT_CARD' | 'PIX' | 'PAYPAL'): void {
    if (method === 'CREDIT_CARD') {
      console.log(`Processing $${amount} via Credit Card...`);
      // Complex logic for acquirer integration...
    }
    else if (method === 'PIX') {
      console.log(`Processing $${amount} via Pix key...`);
      // Complex logic for QRCode generation...
    }
    else if (method === 'PAYPAL') {
      console.log(`Processing $${amount} via PayPal...`);
      // Complex redirection logic...
    }
    else {
      throw new Error('Payment method not supported.');
    }
  }
}

GOOD EXAMPLE

Just fulfill the “IPaymentMethod” contract and the method is already valid.

We can then add a “DebitCardPayment”, without affecting the other methods.

Code Example:

// 1. The Abstraction (The Contract)
interface IPaymentMethod {
  processPayment(amount: number): void;
}

// 2. The Extensions (New isolated behaviors)
class CreditCardPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processing $${amount} via Credit Card...`);
  }
}

class PixPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processing $${amount} via Pix key...`);
  }
}

// 3. The Closed Application (The Consumer)
class PaymentProcessor {
  public process(amount: number, paymentMethod: IPaymentMethod): void {
    paymentMethod.processPayment(amount);
  }
}

// Practical use:
const processor = new PaymentProcessor();
processor.process(150.0, new PixPayment());

IS IT REALLY THAT IMPORTANT?

Without hesitation, yes, very much!

Rework is expensive: it is wasted labor, planning, and time.

And besides that, constantly altering already “finished” code opens up more loopholes to break a business rule or feature that was already working.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Have you ever needed to refactor old code because of poorly applied OCP?

PRINCÍPIO DE ABERTO/FECHADO

Victor Lis Bronzo — Tue, 14 Jul 2026 23:54:50 +0000

OPEN - CLOSED PRINCIPLE

As partes integrantes de um código devem ser abertas para extensão e fechadas para modificações.

A ideia é evitar a dependência de verificações condicionais com if-else, operadores ternários e switch.

Quando um novo requisito chegar, você adiciona o comportamento criando algo novo, sem modificar o código antigo.

PRA SER JUSTO

A ideia de não usar operadores condicionais é um resultado de uma aplicação correta do OCP, não é o foco em si.

Isso porque para conseguir não depender desses operadores é necessário excelência na aplicação de polimorfismo e abstração.

Com isso, se torna possível acoplar novas implementações sem reescrever o código já existente.

EXEMPLO RUIM

Todo novo meio de pagamento causará uma edição aqui. Dificulta em novas implementações e põe em risco as antigas.

Exemplo de Código:

// RUIM: Forte acoplamento. A classe precisa ser modificada a cada nova regra.
class PaymentProcessor {
  public process(amount: number, method: 'CREDIT_CARD' | 'PIX' | 'PAYPAL'): void {
    if (method === 'CREDIT_CARD') {
      console.log(`Processando R$${amount} via Cartão de Crédito...`);
      // Lógica complexa de integração com a adquirente...
    }
    else if (method === 'PIX') {
      console.log(`Processando R$${amount} via chave Pix...`);
      // Lógica complexa de geração de QRCode...
    }
    else if (method === 'PAYPAL') {
      console.log(`Processando R$${amount} via PayPal...`);
      // Lógica complexa de redirecionamento...
    }
    else {
      throw new Error('Método de pagamento não suportado.');
    }
  }
}

EXEMPLO BOM

Basta cumprir o contrato “IPaymentMethod” e o método já é válido.

Conseguimos então adicionar um “DebitCardPayment”, sem afetar os demais métodos.

Exemplo de Código:

// 1. A Abstração (O Contrato)
interface IPaymentMethod {
  processPayment(amount: number): void;
}

// 2. As Extensões (Novos comportamentos isolados)
class CreditCardPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processando R$${amount} via Cartão de Crédito...`);
  }
}

class PixPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processando R$${amount} via chave Pix...`);
  }
}

// 3. A Aplicação Fechada (O Consumidor)
class PaymentProcessor {
  public process(amount: number, paymentMethod: IPaymentMethod): void {
    paymentMethod.processPayment(amount);
  }
}

// Uso prático:
const processor = new PaymentProcessor();
processor.process(150.0, new PixPayment());

É MESMO TÃO IMPORTANTE?

Sem titubear, sim e muito!

Retrabalho é caro: é mão de obra, planejamento e tempo desperdiçados.

E além disso, ficar constantemente alterando código já “finalizado” abre mais brechas para quebrar uma regra de negócio ou feature que já funcionava.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você já precisou refatorar código antigo por ter aplicado mal o OCP?

SINGLE RESPONSIBILITY PRINCIPLE

Victor Lis Bronzo — Mon, 13 Jul 2026 20:35:26 +0000

SINGLE RESPONSIBILITY PRINCIPLE (SRP)

A class should have one, and exclusively one, reason to change.

In other words, we shouldn't have a single class doing everything: receiving data, validating requests, applying business rules, and accessing the database...

This class that “does it all” is the famous God Class, and it is an anti-pattern.

IS IT REALLY THAT IMPORTANT?

An analogy that explains its importance well is the comparison between a Swiss Army Knife vs. a Scalpel.

I know it might sound weird at first, but let's break it down. A pocket knife can be quite useful, carrying a bunch of functionalities at once, being practical in everyday life.

But what if one tool in it breaks?

POINT FOR SPECIALIZATION

You will have to buy another one, even if all the other tools are working well. A waste, right? This applied to software is even worse.

On the other hand, the scalpel, besides having fewer chances of breaking, is a specialist in its own function. You will only replace the scalpel if it actually has a problem.

CONNECTION TO ARCHITECTURE

In practice, SRP is the foundation for organizing the structure of your project.

A class that only serves a single responsibility helps in understanding architectures like MVC, Hexagonal, Clean Arch...

This principle determines that it makes no sense to have a class that defines attributes, validates fields, saves data to the database... In this scenario, the class would assume multiple responsibilities, which violates the precepts of any of these architectures.

A BAD EXAMPLE

This class below fulfills more than one responsibility. A class that deals with persistence, validation, business rules... violates the SRP.

Code Example (The Anti-pattern):

class UserService {
  constructor(
    private name: string,
    private email: string,
  ) {}

  // Responsibility 1: Data Validation
  public validateEmail(): boolean {
    return this.email.includes("@");
  }

  // Responsibility 2: Data Persistence (Database Access)
  public saveToDatabase(): void {
    console.log(`Saving user ${this.name} to MySQL database...`);
  }

  // Responsibility 3: Sending Notifications
  public sendWelcomeEmail(): void {
    console.log(`Sending welcome email to ${this.email}...`);
  }

  // Responsibility 4: Report Generation (Presentation/Visualization)
  public generateUserReportPDF(): void {
    console.log(`Generating PDF report for ${this.name}...`);
  }

  // Responsibility 5: Infrastructure (Error Logging)
  public logSystemError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

AND WHAT WOULD BE A GOOD EXAMPLE?

It would be extracting all these responsibilities (Persistence, Business Rule, Validation, Boundary...) from a single class.

And exactly because of this, SRP communicates so well with architectures and their layers. Using the famous "Clean Arch" as an example, each of its layers will assume a well-defined responsibility.

Code Example (Applying SRP):

// ✅ SOLID: Each class has only one reason to change

class UserValidator {
  public isValidEmail(email: string): boolean {
    return email.includes("@");
  }
}

class UserRepository {
  public save(user: User): void {
    console.log(`Saving user ${user.name} to database...`);
  }
}

class EmailService {
  public sendWelcomeEmail(email: string): void {
    console.log(`Sending welcome email to ${email}...`);
  }
}

class ReportGenerator {
  public generateUserPDF(user: User): void {
    console.log(`Generating PDF report for ${user.name}...`);
  }
}

class Logger {
  public logError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

SRP + CLEAN ARCH

Each layer fulfills only its responsibility and passes it on to the next layer, following the flow. The detail is that, depending on the size of the project, the team, and the needs, the layers can increase or decrease.

ROUTE: Receives the HTTP request and directs the traffic.
CONTROLLER: Validates the input data and formats the final response.
SERVICE: Orchestrates the application rules and entities.
REPOSITORY: Isolates the database and executes the persistence.

OTHER CASES

The previous example focused on Clean Arch, but other architectural approaches, like MVC and Hexagonal, also apply SRP to their core.

SOLID acts as a foundation for these patterns, not as a competitor.

In practice, the division of responsibilities ends up being implicit in the very definition of the layers of any good architecture:
⬇️ user.route.ts
⬇️ user.controller.ts
⬇️ user.service.ts
⬇️ user.repository.ts

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Had you already realized the importance of SRP?

PRINCÍPIO DA RESPONSABILIDADE ÚNICA

Victor Lis Bronzo — Mon, 13 Jul 2026 20:34:04 +0000

PRINCÍPIO DA RESPONSABILIDADE ÚNICA

Em Inglês: SINGLE RESPONSIBILITY PRINCIPLE (SRP)

Uma classe deve ter um, e exclusivamente um, motivo para ser alterada.

Ou seja, não devemos ter uma única classe fazendo de tudo: recebendo dados, validando requisições, aplicando regras de negócio e acessando o banco de dados...

Essa classe que “faz tudo” é a famosa God Class, e é um anti-pattern.

É MESMO TÃO IMPORTANTE?

Uma analogia que explica bem a importância, é a comparação entre Canivete Suíço vs. Bisturi.

Eu sei que pode soar esquisito de primeira, mas vamos destrinchar. Um canivete até pode ser bem útil, carregando um monte de funcionalidades de uma vez, sendo prático no dia a dia.

Mas e se uma ferramenta dele quebrar?

PONTO PARA ESPECIALIZAÇÃO

Você vai ter que comprar outro, mesmo que todas as outras ferramentas estejam funcionando bem. Um desperdício né? Isso aplicado em software fica pior ainda.

Já o bisturi, além de ter menos possibilidades de quebrar, ele é especialista na própria função. Você só vai trocar o bisturi, se ele realmente tiver algum problema.

CONEXÃO COM ARQUITETURA

Na prática, o SRP é a base para organizar a estrutura do seu projeto.

Uma classe que só atende a uma única responsabilidade ajuda na compreensão de arquiteturas como MVC, Hexagonal, Clean Arch...

Esse princípio determina que não faz sentido você ter uma classe que define atributos, valida campos, salva dados no banco... Nesse cenário, a classe assumiria múltiplas responsabilidades, o que viola os preceitos de qualquer uma dessas arquiteturas.

UM MAU EXEMPLO

Essa classe abaixo cumpre mais de uma responsabilidade. Uma classe que lida com persistência, validação, regras de negócio... fere o SRP.

Exemplo de Código (O Anti-pattern):

class UserService {
  constructor(
    private name: string,
    private email: string,
  ) {}

  // Responsabilidade 1: Validação de Dados
  public validateEmail(): boolean {
    return this.email.includes("@");
  }

  // Responsabilidade 2: Persistência de Dados (Acesso ao Banco de Dados)
  public saveToDatabase(): void {
    console.log(`Saving user ${this.name} to MySQL database...`);
  }

  // Responsabilidade 3: Envio de Notificações
  public sendWelcomeEmail(): void {
    console.log(`Sending welcome email to ${this.email}...`);
  }

  // Responsabilidade 4: Geração de Relatórios (Apresentação/Visualização)
  public generateUserReportPDF(): void {
    console.log(`Generating PDF report for ${this.name}...`);
  }

  // Responsabilidade 5: Infraestrutura (Log de Erros)
  public logSystemError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

E O QUE SERIA UM BOM EXEMPLO?

Seria extrair todas essas responsabilidades (Persistência, Regra de Negócio, Validação, Fronteira...) de uma única classe.

E justamente por isso, o SRP conversa tão bem com arquiteturas e suas camadas. Usando a famosa "Clean Arch" como exemplo, cada uma de suas camadas vai assumir uma responsabilidade bem definida.

Exemplo de Código (Aplicando o SRP):

// ✅ SOLID: Cada classe tem apenas um motivo para mudar

class UserValidator {
  public isValidEmail(email: string): boolean {
    return email.includes("@");
  }
}

class UserRepository {
  public save(user: User): void {
    console.log(`Saving user ${user.name} to database...`);
  }
}

class EmailService {
  public sendWelcomeEmail(email: string): void {
    console.log(`Sending welcome email to ${email}...`);
  }
}

class ReportGenerator {
  public generateUserPDF(user: User): void {
    console.log(`Generating PDF report for ${user.name}...`);
  }
}

class Logger {
  public logError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

SRP + CLEAN ARCH

Cada camada cumpre apenas sua responsabilidade e repassa para a próxima camada, seguindo o fluxo. O detalhe é que, dependendo do tamanho do projeto, da equipe e das necessidades, as camadas podem aumentar ou diminuir.

ROUTE: Recebe a requisição HTTP e direciona o tráfego.
CONTROLLER: Valida os dados de entrada e formata a resposta final.
SERVICE: Orquestra as regras da aplicação e as entidades.
REPOSITORY: Isola o banco de dados e executa a persistência.

OUTROS CASOS

O exemplo anterior focou em Clean Arch, mas outras abordagens arquiteturais, como MVC e Hexagonal, também aplicam o SRP em suas bases.

O SOLID atua como um alicerce para esses padrões, não como um concorrente.

Na prática, a divisão de responsabilidades acaba ficando implícita na própria definição das camadas de qualquer boa arquitetura:
⬇️ user.route.ts
⬇️ user.controller.ts
⬇️ user.service.ts
⬇️ user.repository.ts

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você já tinha percebido a importância do SRP?