Design Patterns para back-end: o vocabulário que separa código de engenharia

Por que código bem escrito ainda pode ser um pesadelo de manutenção?

Você pode escrever código sintaticamente correto, com variáveis bem nomeadas, sem bugs aparentes — e ainda assim criar um sistema que nenhum desenvolvedor quer tocar seis meses depois. O problema não está na sintaxe. Está na estrutura. Design patterns existem precisamente para resolver isso: são soluções consolidadas para problemas recorrentes de estruturação de código que toda equipe enfrenta, independentemente de linguagem ou porte do projeto.

Na aula anterior ([SIS]ANO2C2B2S8A1), comparamos arquitetura monolítica e microsserviços. Agora a pergunta muda: dado que você escolheu sua arquitetura, como organiza o código dentro dela? É aí que os padrões de design entram — não como regras obrigatórias, mas como vocabulário compartilhado que torna decisões de design comunicáveis e replicáveis.

Como ensinar design patterns no ensino médio técnico sem perder a objetividade?

A aula [SIS]ANO2C2B2S8A2 resolve um problema didático real: padrões de design têm reputação de abstratos e difíceis de contextualizar. A estratégia da SEDUC-SP é eficiente — um sistema de e-commerce como âncora narrativa, passando do monolito para microsserviços em Python executável no Google Colab. O estudante não aprende um padrão no vácuo: aprende quando e por que aplicá-lo num problema que já conhece.

Quais design patterns se aplicam a cada arquitetura?

Padrões para arquitetura monolítica

Padrões para arquitetura de microsserviços

Como implementar a transição monolito → microsserviços em Python?

Passo 1 — Sistema monolítico

# Arquitetura Monolítica — todas as responsabilidades em uma única classe
class EcommerceSystem:
    def __init__(self):
        self.users = []; self.products = []; self.orders = []

    def add_user(self, user): self.users.append(user)
    def add_product(self, product): self.products.append(product)

    def place_order(self, user, product):
        if product in self.products:
            self.orders.append((user, product))
            return "Order placed successfully"
        return "Product not available"

system = EcommerceSystem()
system.add_user("Alice"); system.add_product("Laptop")
print(system.place_order("Alice", "Laptop"))  # Order placed successfully

Passo 2 — Refatoração para microsserviços com injeção de dependência

# Microsserviços — cada classe com responsabilidade única e bem definida
class UserService:
    def __init__(self): self.users = []
    def add_user(self, user): self.users.append(user)

class ProductService:
    def __init__(self): self.products = []
    def add_product(self, product): self.products.append(product)
    def check_availability(self, product):
        return product in self.products  # contrato de interface público

class OrderService:
    def __init__(self): self.orders = []
    def place_order(self, user, product, product_service):
        # injeção de dependência — recebe serviço externo como parâmetro
        if product_service.check_availability(product):
            self.orders.append((user, product))
            return "Order placed successfully"
        return "Product not available"

user_svc = UserService(); prod_svc = ProductService(); ord_svc = OrderService()
user_svc.add_user("Alice"); prod_svc.add_product("Laptop")
print(ord_svc.place_order("Alice", "Laptop", prod_svc))  # Output idêntico

Como os padrões de design aparecem em uma atividade prática real?

Perguntas frequentes sobre design patterns

Design patterns como mentalidade, não como memorização

A habilidade real não está em saber o nome de 23 padrões do livro Gang of Four — está em reconhecer, diante de um problema de código, que aquele problema já foi resolvido antes, de forma elegante, e que existe um vocabulário para comunicar essa solução ao time. Isso é o que separa o desenvolvedor que escreve código que funciona do engenheiro que projeta sistemas que duram.