DEV Community: joaofelipefaria

Design patterns d'intégration : ce qu'ils sont et lesquels reviennent souvent en entretien

joaofelipefaria — Fri, 09 Oct 2026 12:43:44 +0000

Ce qu'ils sont et ce qu'ils ne sont pas

Un design pattern d'intégration est une solution réutilisable à un problème de communication entre systèmes distincts : des applications différentes, avec leurs propres réseaux, pannes, formats et temps de réponse. Ne le confondez pas avec deux autres familles :

Patterns GoF (Gamma, Helm, Johnson, Vlissides, 1994, 23 patterns) : ils organisent les classes et les objets au sein d'un même processus. Exemples : Strategy, Factory, Decorator. Observer ressemble à Publish-Subscribe, mais il fonctionne en mémoire, dans une seule application, sans réseau, sans persistance et sans panne partielle.
Patterns web (comme les patterns de présentation de Patterns of Enterprise Application Architecture, Fowler, 2002) : ils structurent la couche qui traite les requêtes HTTP d'une application. Exemples : MVC, Front Controller, Page Controller, Template View.
Patterns d'intégration : ils traitent de ce qui se passe entre les applications. Comment livrer un message sans le perdre, comment le router, comment éviter que la panne d'un service entraîne les autres, comment garder la cohérence sans transaction distribuée.

En résumé, par échelle : le GoF vit dans le code, le web vit dans la requête, l'intégration vit entre les systèmes.

Références principales

Hohpe, G. ; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003. Un catalogue de 65 patterns, centré sur la messagerie et indépendant de la technologie.
Richardson, C. Microservices Patterns. Manning, 2018. Patterns d'architecture de microservices, dont les données distribuées et la résilience. La liste ci-dessous provient du pattern language de microservices.io (53 patterns), qui continue d'évoluer et peut contenir des éléments postérieurs au livre de 2018.

Quatre patterns qui reviennent souvent en entretien

Publish-Subscribe Channel

(Hohpe et Woolf, Enterprise Integration Patterns)

Le producteur publie un événement et tous les abonnés en reçoivent une copie, sans qu'il sache qui ils sont. Le service de commandes publie CommandeCréée, et le stock, la facturation et les notifications réagissent de façon indépendante.

Questions typiques : la différence avec Point-to-Point, ce qui arrive à un abonné hors ligne (Durable Subscriber) et comment gérer les doublons.

Circuit Breaker

(Richardson, Microservices Patterns)

Un proxy compte les échecs d'un service distant. Au-delà d'un seuil, le circuit s'ouvre et les appels échouent immédiatement, au lieu d'épuiser les threads dans des timeouts. Après un délai, il laisse passer quelques appels de test (semi-ouvert) et se referme s'ils réussissent. Cela évite les défaillances en cascade.

Questions typiques : les trois états, la différence avec retry et timeout, et quel fallback utiliser.

Saga

(Richardson, Microservices Patterns)

Elle remplace la transaction distribuée par une séquence de transactions locales, avec des transactions compensatoires quand une étape échoue. Créer la commande → réserver le stock → encaisser ; si l'encaissement échoue, on libère le stock et on annule la commande. Elle peut être chorégraphiée (les services réagissent aux événements) ou orchestrée (un coordinateur pilote les étapes). Le coût est la cohérence à terme.

Questions typiques : chorégraphie vs orchestration, et pourquoi ne pas utiliser le 2PC.

Transactional Outbox

(Richardson, Microservices Patterns)

Il résout le problème du dual write : enregistrer en base et publier sur le broker sans qu'un seul des deux n'aboutisse. Le message est écrit dans une table outbox dans la même transaction locale que la donnée métier, puis un relais le publie, par polling (Polling Publisher) ou en lisant le journal de la base (Transaction Log Tailing, comme Debezium). La livraison est at-least-once, donc le consommateur doit être idempotent.

Questions typiques : pourquoi ne pas publier juste après le commit, et comment éviter les doublons.

Ces quatre patterns sont une sélection fondée sur l'expérience du marché, pas un classement sourcé.

Liste : Enterprise Integration Patterns (65)

Source : Hohpe, G. ; Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.

Styles d'intégration : File Transfer, Shared Database, Remote Procedure Invocation, Messaging
Systèmes de messagerie : Message Channel, Message, Pipes and Filters, Message Router, Message Translator, Message Endpoint
Canaux : Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus
Construction des messages : Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator
Routage : Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker
Transformation : Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model
Endpoints : Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator
Gestion du système : Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger

Liste : Microservices Patterns (53)

Source : Richardson, C. Microservices Patterns. Manning, 2018, d'après le pattern language de microservices.io (qui peut inclure des éléments postérieurs au livre).

Style architectural : Monolithic Architecture, Microservice Architecture
Frontières des services : Decompose by Business Capability, Decompose by Subdomain, Self-contained Service, Service per Team
Refactorisation : Strangler Application, Anti-corruption Layer
Collaboration entre services : Database per Service, Shared Database, Saga, Command-side Replica, API Composition, CQRS, Domain Event, Event Sourcing
Messagerie transactionnelle : Transactional Outbox, Transaction Log Tailing, Polling Publisher
Tests : Consumer-driven Contract Test, Consumer-side Contract Test, Service Component Test
Déploiement : Multiple Service Instances per Host, Service Instance per Host, Service Instance per VM, Service Instance per Container, Serverless Deployment, Service Deployment Platform
Préoccupations transverses : Microservice Chassis, Externalized Configuration, Service Template
Communication : Remote Procedure Invocation, Messaging, Domain-specific Protocol, Idempotent Consumer
API externe : API Gateway, Backend for Front-end
Découverte de services : Client-side Discovery, Server-side Discovery, Service Registry, Self Registration, 3rd Party Registration
Fiabilité : Circuit Breaker
Sécurité : Access Token
Observabilité : Log Aggregation, Application Metrics, Audit Logging, Distributed Tracing, Exception Tracking, Health Check API, Log Deployments and Changes
UI : Server-side Page Fragment Composition, Client-side UI Composition

Integration Design Patterns: What They Are and Which Ones Tend to Show Up in Interviews

joaofelipefaria — Fri, 09 Oct 2026 12:43:02 +0000

What they are and what they are not

An integration design pattern is a reusable solution to a problem of communication between separate systems: different applications, each with its own network, failures, formats, and response times. Do not confuse it with two other families:

GoF patterns (Gamma, Helm, Johnson, Vlissides, 1994, 23 patterns): organize classes and objects inside a single process. Examples: Strategy, Factory, Decorator. Observer resembles Publish-Subscribe, but it works in memory, inside one application, with no network, no persistence, and no partial failure.
Web patterns (such as the presentation patterns in Patterns of Enterprise Application Architecture, Fowler, 2002): structure the layer that handles an application's HTTP requests. Examples: MVC, Front Controller, Page Controller, Template View.
Integration patterns: deal with what happens between applications. How to deliver a message without losing it, how to route it, how to keep one service's failure from taking down the others, how to keep data consistent without a distributed transaction.

In short, by scale: GoF lives in the code, web lives in the request, integration lives between systems.

Main references

Hohpe, G.; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003. A catalog of 65 patterns, centered on messaging and technology-independent.
Richardson, C. Microservices Patterns. Manning, 2018. Microservice architecture patterns, including distributed data and resilience. The list below comes from the pattern language at microservices.io (53 patterns), which keeps evolving and may include items added after the 2018 book.

Four patterns that tend to show up in interviews

Publish-Subscribe Channel

(Hohpe and Woolf, Enterprise Integration Patterns)

The producer publishes an event and every subscriber receives a copy, without the producer knowing who they are. The orders service publishes OrderCreated, and inventory, billing, and notifications react independently.

Typical questions: how it differs from Point-to-Point, what happens to an offline subscriber (Durable Subscriber), and how to handle duplicates.

Circuit Breaker

(Richardson, Microservices Patterns)

A proxy counts the failures of a remote service. Past a threshold, the circuit opens and calls fail immediately instead of exhausting threads on timeouts. After a while, it lets a few test calls through (half-open) and closes again if they succeed. This prevents cascading failures.

Typical questions: the three states, how it differs from retry and timeout, and which fallback to use.

Saga

(Richardson, Microservices Patterns)

Replaces the distributed transaction with a sequence of local transactions, plus compensating transactions when a step fails. Create order → reserve stock → charge payment; if the charge fails, the stock is released and the order is canceled. It can be choreographed (services react to events) or orchestrated (a coordinator drives the steps). The cost is eventual consistency.

Typical questions: choreography vs. orchestration, and why not use 2PC.

Transactional Outbox

(Richardson, Microservices Patterns)

Solves the dual write problem: saving to the database and publishing to the broker without only one of the two happening. The message is written to an outbox table in the same local transaction as the business data, and a relay publishes it later, by polling (Polling Publisher) or by reading the database log (Transaction Log Tailing, as Debezium does). Delivery is at-least-once, so the consumer must be idempotent.

Typical questions: why not publish right after the commit, and how to avoid duplicates.

These four are a selection based on market experience, not a sourced ranking.

List: Enterprise Integration Patterns (65)

Source: Hohpe, G.; Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.

Integration styles: File Transfer, Shared Database, Remote Procedure Invocation, Messaging
Messaging systems: Message Channel, Message, Pipes and Filters, Message Router, Message Translator, Message Endpoint
Channels: Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus
Message construction: Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator
Routing: Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker
Transformation: Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model
Endpoints: Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator
System management: Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger

List: Microservices Patterns (53)

Source: Richardson, C. Microservices Patterns. Manning, 2018, as listed in the pattern language at microservices.io (which may include items added after the book).

Architectural style: Monolithic Architecture, Microservice Architecture
Service boundaries: Decompose by Business Capability, Decompose by Subdomain, Self-contained Service, Service per Team
Refactoring: Strangler Application, Anti-corruption Layer
Service collaboration: Database per Service, Shared Database, Saga, Command-side Replica, API Composition, CQRS, Domain Event, Event Sourcing
Transactional messaging: Transactional Outbox, Transaction Log Tailing, Polling Publisher
Testing: Consumer-driven Contract Test, Consumer-side Contract Test, Service Component Test
Deployment: Multiple Service Instances per Host, Service Instance per Host, Service Instance per VM, Service Instance per Container, Serverless Deployment, Service Deployment Platform
Cross-cutting concerns: Microservice Chassis, Externalized Configuration, Service Template
Communication: Remote Procedure Invocation, Messaging, Domain-specific Protocol, Idempotent Consumer
External API: API Gateway, Backend for Front-end
Service discovery: Client-side Discovery, Server-side Discovery, Service Registry, Self Registration, 3rd Party Registration
Reliability: Circuit Breaker
Security: Access Token
Observability: Log Aggregation, Application Metrics, Audit Logging, Distributed Tracing, Exception Tracking, Health Check API, Log Deployments and Changes
UI: Server-side Page Fragment Composition, Client-side UI Composition

Design patterns de integração: o que são e quais costumam aparecer em entrevistas

joaofelipefaria — Fri, 09 Oct 2026 12:42:21 +0000

O que são e o que não são

Design pattern de integração é uma solução reutilizável para um problema de comunicação entre sistemas separados: aplicações diferentes, com redes, falhas, formatos e tempos de resposta próprios. Não confunda com duas outras famílias:

Patterns GoF (Gamma, Helm, Johnson, Vlissides, 1994, 23 patterns): organizam classes e objetos dentro de um mesmo processo. Exemplos: Strategy, Factory, Decorator. O Observer lembra o Publish-Subscribe, mas opera em memória, numa mesma aplicação, sem rede, sem persistência e sem falha parcial.
Patterns web (como os de apresentação em Patterns of Enterprise Application Architecture, Fowler, 2002): estruturam a camada que atende requisições HTTP de uma aplicação. Exemplos: MVC, Front Controller, Page Controller, Template View.
Patterns de integração: tratam do que acontece entre aplicações. Como entregar uma mensagem sem perdê-la, como rotear, como evitar que a falha de um serviço derrube os outros, como manter consistência sem transação distribuída.

Resumindo pela escala: GoF vive no código, web vive na requisição, integração vive entre sistemas.

Referências principais

Hohpe, G.; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003. Catálogo de 65 patterns, centrado em mensageria e independente de tecnologia.
Richardson, C. Microservices Patterns. Manning, 2018. Patterns de arquitetura de microsserviços, incluindo dados distribuídos e resiliência. A lista abaixo vem da pattern language do microservices.io (53 patterns), que continua evoluindo e pode ter itens posteriores ao livro de 2018.

Quatro patterns que costumam aparecer em entrevistas

Publish-Subscribe Channel

(Hohpe e Woolf, Enterprise Integration Patterns)

O produtor publica um evento e todos os assinantes recebem uma cópia, sem que ele saiba quem são. O serviço de pedidos publica PedidoCriado, e estoque, faturamento e notificações reagem de forma independente.

Perguntas típicas: diferença para Point-to-Point, o que acontece com assinante offline (Durable Subscriber) e como lidar com duplicatas.

Circuit Breaker

(Richardson, Microservices Patterns)

Um proxy conta as falhas de um serviço remoto. Passando de um limite, o circuito abre e as chamadas falham na hora, em vez de esgotar threads em timeouts. Após um tempo, ele deixa passar chamadas de teste (meio aberto) e fecha se elas funcionarem. Isso evita falha em cascata.

Perguntas típicas: os três estados, a diferença para retry e timeout, e qual fallback usar.

Saga

(Richardson, Microservices Patterns)

Troca a transação distribuída por uma sequência de transações locais, com transações compensatórias quando um passo falha. Criar pedido → reservar estoque → cobrar; se a cobrança falha, libera-se o estoque e cancela-se o pedido. Pode ser coreografada (serviços reagem a eventos) ou orquestrada (um coordenador comanda). O custo é a consistência eventual.

Perguntas típicas: coreografia vs. orquestração, e por que não usar 2PC.

Transactional Outbox

(Richardson, Microservices Patterns)

Resolve o dual write: salvar no banco e publicar no broker sem que só um dos dois aconteça. A mensagem é gravada numa tabela outbox na mesma transação local do dado de negócio, e um relay a publica depois, por polling (Polling Publisher) ou lendo o log do banco (Transaction Log Tailing, como o Debezium). A entrega é at-least-once, então o consumidor precisa ser idempotente.

Perguntas típicas: por que não publicar direto após o commit, e como evitar duplicatas.

Esses quatro são uma seleção baseada em experiência de mercado, não um ranking com fonte.

Lista: Enterprise Integration Patterns (65)

Fonte: Hohpe, G.; Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.

Estilos de integração: File Transfer, Shared Database, Remote Procedure Invocation, Messaging
Sistemas de mensageria: Message Channel, Message, Pipes and Filters, Message Router, Message Translator, Message Endpoint
Canais: Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus
Construção de mensagens: Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator
Roteamento: Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker
Transformação: Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model
Endpoints: Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator
Gerenciamento: Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger

Lista: Microservices Patterns (53)

Fonte: Richardson, C. Microservices Patterns. Manning, 2018, conforme a pattern language em microservices.io (que pode incluir itens posteriores ao livro).

Estilo arquitetural: Monolithic Architecture, Microservice Architecture
Fronteiras de serviço: Decompose by Business Capability, Decompose by Subdomain, Self-contained Service, Service per Team
Refatoração: Strangler Application, Anti-corruption Layer
Colaboração entre serviços: Database per Service, Shared Database, Saga, Command-side Replica, API Composition, CQRS, Domain Event, Event Sourcing
Mensageria transacional: Transactional Outbox, Transaction Log Tailing, Polling Publisher
Testes: Consumer-driven Contract Test, Consumer-side Contract Test, Service Component Test
Deployment: Multiple Service Instances per Host, Service Instance per Host, Service Instance per VM, Service Instance per Container, Serverless Deployment, Service Deployment Platform
Cross-cutting: Microservice Chassis, Externalized Configuration, Service Template
Comunicação: Remote Procedure Invocation, Messaging, Domain-specific Protocol, Idempotent Consumer
API externa: API Gateway, Backend for Front-end
Service discovery: Client-side Discovery, Server-side Discovery, Service Registry, Self Registration, 3rd Party Registration
Confiabilidade: Circuit Breaker
Segurança: Access Token
Observabilidade: Log Aggregation, Application Metrics, Audit Logging, Distributed Tracing, Exception Tracking, Health Check API, Log Deployments and Changes
UI: Server-side Page Fragment Composition, Client-side UI Composition

[FR] Design patterns : d'où viennent-ils ?

joaofelipefaria — Mon, 28 Sep 2026 12:06:29 +0000

Une discussion sur les patrons de conception

L'un des sujets qui suscitent le plus de curiosité (et de confusion) chez les personnes qui entrent dans le monde du développement, ce sont les design patterns. Dans cette petite discussion, je vais essayer de clarifier quelques points sur les patrons de conception.

Qu'est-ce qu'un design pattern ?

Les design patterns sont des solutions techniques utilisées pour résoudre des problèmes récurrents du développement logiciel. Parmi les plus connus et les plus cités dans les conversations sur le logiciel, on trouve : Factory, DAO, DTO, Message Outbox et Pub/Sub.

Là où commence la confusion

C'est ici que la confusion commence. Beaucoup de jeunes développeurs, ne connaissant pas l'origine de ces patterns, ne réalisent pas qu'ils viennent de mondes totalement différents. Avant de nous mettre à les définir, comprenons donc les principaux groupes et d'où ils sont issus.

Les patterns GoF : la programmation orientée objet

Les patterns GoF sont des patrons pour la programmation orientée objet. Le nom vient du « Gang of Four » (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides), auteurs du livre Design Patterns: Elements of Reusable Object-Oriented Software, publié en 1994. Parmi les principaux : Singleton, Factory Method et Observer.

Les JEE BluePrint Patterns : les applications web

Les JEE BluePrint Patterns sont des patrons pour le développement d'applications web d'entreprise. Ils sont nés dans l'écosystème Java EE (anciennement J2EE), à partir du programme Java BluePrints de Sun Microsystems, et ont été catalogués dans le livre Core J2EE Patterns, paru en 2001. Parmi les principaux : DAO, DTO et Front Controller.

Les patterns de messagerie : l'intégration entre systèmes

Les patterns de messagerie traitent de la communication asynchrone et de l'intégration entre systèmes au moyen de messages. Leur référence principale est le livre Enterprise Integration Patterns, de Gregor Hohpe et Bobby Woolf, publié en 2003, et le sujet a pris encore plus d'ampleur avec l'arrivée des microservices. Parmi les principaux : Publish/Subscribe, Dead Letter Channel et Transactional Outbox.

Et il en existe d'autres

Il existe d'autres familles, comme les patterns d'UI/UX, qui portent sur la façon de concevoir les interfaces et les interactions. Deux exemples : le Breadcrumb (fil d'Ariane) et l'Infinite Scroll. Il existe aussi des patterns pour l'IA, des patterns d'architecture, parmi bien d'autres.

Prochaines étapes

Dans les prochains articles, nous approfondirons ces familles de patterns, une par une. Nous définirons les patterns, comprendrons le problème qu'ils résolvent et verrons comment les implémenter dans vos projets.

[EN] Design patterns: where do they come from?

joaofelipefaria — Mon, 28 Sep 2026 12:05:50 +0000

A chat about design patterns

One of the topics I see sparking the most curiosity (and confusion) among people entering the world of software development is design patterns. In this short chat, I'll try to clear up a few things about them.

What are design patterns?

Design patterns are technical solutions used to solve recurring problems in software development. Some of the best known and most frequently mentioned in conversations about software are: Factory, DAO, DTO, Message Outbox and Pub/Sub.

Where the confusion starts

And this is where the confusion begins. Many younger developers, not knowing where these patterns come from, don't realize they originate from completely different worlds. So before we start defining patterns, let's understand the main groups and where they came from.

GoF Patterns: object-oriented programming

GoF Patterns are patterns for object-oriented programming. The name comes from the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides), the authors of the book Design Patterns: Elements of Reusable Object-Oriented Software, published in 1994. Among the main ones are Singleton, Factory Method and Observer.

JEE BluePrint Patterns: web applications

JEE BluePrint Patterns are patterns for developing enterprise web applications. They came out of the Java EE (formerly J2EE) ecosystem, from Sun Microsystems' Java BluePrints program, and were cataloged in the 2001 book Core J2EE Patterns. Among the main ones are DAO, DTO and Front Controller.

Messaging patterns: integrating systems

Messaging patterns deal with asynchronous communication and integration between systems through messages. Their main reference is the book Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf, published in 2003, and the topic gained even more traction with the rise of microservices. Among the main ones are Publish/Subscribe, Dead Letter Channel and Transactional Outbox.

And there are others

There are other families, such as UI/UX patterns, which deal with how we design interfaces and interactions. Two examples are the Breadcrumb and Infinite Scroll. There are also patterns for AI, architecture patterns, and many others.

Next steps

In the next articles, we'll dive deeper into these pattern families, one by one. We'll define the patterns, understand the problem each one solves, and see how to implement them in your projects.

[PT] Design patterns: de onde eles vêm?

joaofelipefaria — Mon, 28 Sep 2026 12:03:42 +0000

Um bate-papo sobre padrões de projeto

Um dos assuntos que mais vejo despertar a curiosidade (e a confusão) de quem está entrando no mundo do desenvolvimento são os design patterns. Neste pequeno bate-papo, vou tentar esclarecer algumas coisas sobre os padrões de projeto.

O que são design patterns?

Design patterns são soluções de tecnologia usadas para resolver problemas recorrentes do desenvolvimento de software. Alguns dos mais conhecidos e mencionados em conversas sobre software são: Factory, DAO, DTO, Message Outbox e Pub/Sub.

Onde começa a confusão

E aqui começa a confusão. Muitos programadores mais jovens, por não conhecerem a origem desses patterns, não percebem que eles vêm de mundos totalmente diferentes. Por isso, antes de sairmos definindo patterns, vamos entender os principais grupos e de onde eles surgiram.

GoF Patterns: orientação a objetos

Os GoF Patterns são padrões para a programação orientada a objetos. O nome vem da "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides), autores do livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1994. Entre os principais estão Singleton, Factory Method e Observer.

JEE BluePrint Patterns: aplicações web

Os JEE BluePrint Patterns são padrões para o desenvolvimento de aplicações web corporativas. Surgiram no ecossistema Java EE (antigo J2EE), a partir do programa Java BluePrints da Sun Microsystems, e foram catalogados no livro Core J2EE Patterns, de 2001. Entre os principais estão DAO, DTO e Front Controller.

Patterns de mensageria: integração entre sistemas

Os patterns de mensageria tratam da comunicação assíncrona e da integração entre sistemas por meio de mensagens. Sua principal referência é o livro Enterprise Integration Patterns, de Gregor Hohpe e Bobby Woolf, publicado em 2003, e o tema ganhou ainda mais força com a chegada dos microsserviços. Entre os principais estão Publish/Subscribe, Dead Letter Channel e Transactional Outbox.

E ainda existem outros

Há outras famílias, como os patterns de UI/UX, que tratam de como projetamos interfaces e interações. Dois exemplos são o Breadcrumb e o Infinite Scroll. Existem ainda patterns para IA, patterns de arquitetura, dentre diversos outros.

Próximos passos

Nos próximos artigos, vamos nos aprofundar nessas famílias de patterns, uma a uma. Vamos definir os patterns, entender o problema que eles resolvem e ver como implementá-los em seus projetos.

[FR] Java en pratique : classes, objets et packages

joaofelipefaria — Mon, 28 Sep 2026 12:02:11 +0000

Java est orienté objet

Java est un langage orienté objet. Concrètement, cela signifie que l'on construit un programme Java en écrivant des classes et en manipulant des objets. La classe est le moule ; l'objet est l'instance créée à partir de ce moule.

Attributs et méthodes

À l'intérieur d'une classe, les méthodes représentent le comportement d'un objet et les attributs représentent son état. Pour rendre cela concret, modélisons une voiture, qui a une marque et une année de fabrication :

package com.exemple.modele;

public class Voiture {

    String marque;
    int annee;
}

Le package

La première déclaration d'un fichier de classe est le package. Il indique dans quel package se trouve la classe et répond à trois objectifs :

éviter les collisions de noms (deux classes portant le même nom peuvent coexister dans des packages différents) ;
regrouper les classes par responsabilité ;
permettre à d'autres classes de les importer.

Créer et utiliser un objet

Dans cet exemple, en plus de Voiture, nous allons créer une seconde classe nommée Application. Elle importe Voiture et, dans la méthode main, crée une voiture, renseigne la marque ("fiat uno") et l'année (2002), puis affiche ces valeurs :

package com.exemple;

import com.exemple.modele.Voiture;

public class Application {

    public static void main(String[] args) {
        Voiture voiture = new Voiture();
        voiture.marque = "fiat uno";
        voiture.annee = 2002;

        System.out.println("Marque : " + voiture.marque);
        System.out.println("Année : " + voiture.annee);
    }
}

En exécutant Application, la console affiche la marque et l'année de la voiture créée. Remarquez que Application se trouve dans un package différent de celui de Voiture ; elle a donc besoin de l'import pour la voir.

Ce que nous avons appris

Avec ce petit exemple, nous avons déjà vu quelques comportements de base du langage : la déclaration de package, la définition d'une classe avec ses attributs, l'importation de classes et l'instanciation d'un objet avec new.

À propos des types

En utilisant les mots-clés String et int, nous définissons le type de chaque attribut : un texte pour la marque et un nombre entier pour l'année. Java est un langage à typage statique, et cela s'applique aux attributs, aux variables et aux paramètres.

Prochaines étapes

Dans les prochains articles, nous approfondirons le typage en Java et explorerons les syntaxes possibles de la méthode main.

[EN] Java in practice: classes, objects and packages

joaofelipefaria — Mon, 28 Sep 2026 12:01:31 +0000

Java is object-oriented

Java is an object-oriented language. In practice, this means we build a Java program by writing classes and manipulating objects. The class is the blueprint; the object is the instance created from it.

Attributes and methods

Inside a class, methods represent an object's behavior and attributes represent its state. To make this concrete, let's model a car, which has a brand and a year of manufacture:

package com.example.model;

public class Car {

    String brand;
    int year;
}

The package

The first statement in a class file is the package declaration. It tells which package the class belongs to and serves three purposes:

avoiding naming collisions (two classes with the same name can coexist in different packages);
grouping classes by responsibility;
allowing other classes to import them.

Creating and using an object

In this example, besides Car, we'll create a second class called Application. It imports Car and, in the main method, creates a car, sets the brand ("fiat uno") and the year (2002), and finally prints both values:

package com.example;

import com.example.model.Car;

public class Application {

    public static void main(String[] args) {
        Car car = new Car();
        car.brand = "fiat uno";
        car.year = 2002;

        System.out.println("Brand: " + car.brand);
        System.out.println("Year: " + car.year);
    }
}

When you run Application, the console prints the brand and year of the car we created. Note that Application lives in a different package from Car, so it needs the import statement to see it.

What we learned

With this small example we've already seen some basic language behaviors: the package declaration, defining a class with its attributes, importing classes, and instantiating an object with new.

About types

By using the keywords String and int, we define the type of each attribute: text for the brand and a whole number for the year. Java is a statically typed language, and this applies to attributes, variables and parameters.

Next steps

In the next articles, we'll dive deeper into typing in Java and explore the possible syntaxes for the main method.

[PT] Java na prática: classes, objetos e pacotes

joaofelipefaria — Mon, 28 Sep 2026 12:00:08 +0000

Java é orientado a objetos

Java é uma linguagem orientada a objetos. Na prática, isso significa que construímos um programa Java codificando classes e manipulando objetos. A classe é o molde; o objeto é a instância criada a partir dele.

Atributos e métodos

Dentro de uma classe, os métodos representam o comportamento de um objeto, e os atributos representam o seu estado. Para deixar isso concreto, vamos modelar um carro, que tem uma marca e um ano de fabricação:

package com.exemplo.modelo;

public class Carro {

    String marca;
    int ano;
}

O pacote (package)

A primeira declaração de um arquivo de classe é o package. Ele informa em qual pacote a classe está e serve a três propósitos:

evitar colisões de nomes (duas classes com o mesmo nome podem coexistir em pacotes diferentes);
agrupar classes por responsabilidade;
permitir que outras classes as importem.

Criando e usando um objeto

Neste exemplo, além de Carro, vamos criar uma segunda classe chamada Application. Ela importa Carro e, no método main, cria um carro, informa a marca ("fiat uno") e o ano (2002) e, por fim, imprime esses valores:

package com.exemplo;

import com.exemplo.modelo.Carro;

public class Application {

    public static void main(String[] args) {
        Carro carro = new Carro();
        carro.marca = "fiat uno";
        carro.ano = 2002;

        System.out.println("Marca: " + carro.marca);
        System.out.println("Ano: " + carro.ano);
    }
}

Ao executar Application, o console exibe a marca e o ano do carro criado. Repare que Application está em um pacote diferente de Carro, e por isso precisa do import para enxergá-la.

O que aprendemos

Com esse pequeno exemplo, já vimos comportamentos básicos da linguagem: a declaração de pacote, a definição de uma classe com seus atributos, a importação de classes e a instanciação de um objeto com new.

Sobre os tipos

Ao usar as palavras-chave String e int, estamos definindo o tipo de cada atributo: um texto para a marca e um número inteiro para o ano. Java é uma linguagem de tipagem estática, e isso vale para atributos, variáveis e parâmetros.

Próximos passos

Nos próximos artigos, vamos aprofundar a tipagem dentro do Java e explorar as sintaxes possíveis para o método main.

[FR] Java et les fondamentaux de la programmation orientée objet

joaofelipefaria — Tue, 15 Sep 2026 09:31:42 +0000

La programmation orientée objet (POO) est l'un des principaux paradigmes de programmation utilisés avec Java. Plus qu'un simple concept de programmation, elle représente une manière très naturelle pour le cerveau humain d'interagir avec son environnement. Lorsque nous entrons dans une pièce, par exemple, nous identifions naturellement les choses qui présentent des caractéristiques similaires et nous les regroupons mentalement : nous reconnaissons des chaises, des tables, des personnes, des portes, etc. Intuitivement, nous sommes en train de classer les éléments en catégories (classes) et d'identifier leurs occurrences concrètes (objets). La POO utilise précisément cette manière de penser pour représenter le monde réel dans un système informatique, en considérant que les objets possèdent un état et un comportement.

L'histoire de la POO a commencé avant Java lui-même, avec des langages comme Simula et Smalltalk, qui ont contribué à établir plusieurs concepts fondamentaux de ce paradigme. Plus tard, des langages comme C++ et Java ont contribué à populariser la programmation orientée objet dans le développement logiciel.

En Java, une classe fonctionne comme un modèle permettant de créer des objets. Elle définit des attributs, qui représentent l'état de l'objet, et des méthodes, qui représentent son comportement. À partir d'une classe Car, par exemple, nous pouvons créer plusieurs voitures différentes, chacune possédant son propre état.

La création d'un objet se fait généralement avec l'opérateur new, comme dans Car myCar = new Car();. À ce moment-là, nous créons une instance concrète de la classe. Les constructeurs permettent d'initialiser ces objets. Ils portent le même nom que la classe et n'ont pas de type de retour.

Un autre concept important est celui des interfaces, qui fonctionnent comme des contrats de comportement. Une interface peut définir des opérations qu'une classe doit implémenter, permettant ainsi à différents types d'objets de respecter le même contrat. Java possède également des membres static, qui appartiennent à la classe elle-même et non à une instance particulière.

Java propose également les blocs d'initialisation, qui permettent d'exécuter du code lors de l'initialisation d'un objet ou du chargement d'une classe. Même s'ils sont moins utilisés dans le développement quotidien, ils font partie des mécanismes d'initialisation disponibles en Java.

Ces concepts constituent la base nécessaire pour comprendre les principes plus avancés de la POO : encapsulation, héritage, polymorphisme, abstraction et composition. Ils permettent de construire des systèmes mieux organisés, réutilisables et plus faciles à maintenir — et c'est précisément sur ces concepts que nous pouvons poursuivre l'étude de la POO en Java.

[EN] Java and the Fundamentals of Object-Oriented Programming

joaofelipefaria — Tue, 15 Sep 2026 09:31:18 +0000

Object-Oriented Programming (OOP) is one of the main programming paradigms used in Java. More than just a programming concept, it represents a very natural way for the human brain to interact with the environment. When we enter a room, for example, we naturally identify things with similar characteristics and group them mentally: we recognize chairs, tables, people, doors, and so on. Intuitively, we are classifying elements into categories (classes) and identifying their concrete occurrences (objects). OOP uses exactly this way of thinking to represent the real world inside a software system, considering that objects have state and behavior.

The history of OOP began before Java itself, with languages such as Simula and Smalltalk, which helped establish many of the fundamental concepts of the paradigm. Later, languages such as C++ and Java helped popularize object-oriented programming in software development.

In Java, a class works as a blueprint for creating objects. It defines attributes, which represent the object's state, and methods, which represent its behavior. From a Car class, for example, we can create several different cars, each with its own state.

An object is normally created using the new operator, as in Car myCar = new Car();. At this point, we are creating a concrete instance of the class. Constructors are used to initialize these objects and have the same name as the class, with no return type.

Another important concept is the interface, which works as a behavioral contract. An interface can define operations that a class must implement, allowing different types of objects to follow the same contract. Java also provides static members, which belong to the class itself rather than to a specific instance.

Java also has initializer blocks, which allow code to be executed during object initialization or when a class is loaded. Although they are less commonly used in everyday development, they are part of Java's available initialization mechanisms.

These concepts form the foundation for understanding the more advanced principles of OOP: encapsulation, inheritance, polymorphism, abstraction, and composition. Together, they allow us to build systems that are more organized, reusable, and easier to maintain — and these are precisely the concepts we should explore next when studying OOP in Java.

[PT] Java e os fundamentos da Programação Orientada a Objetos

joaofelipefaria — Tue, 15 Sep 2026 09:30:35 +0000

A Programação Orientada a Objetos (POO) é um dos principais paradigmas utilizados no desenvolvimento com Java. Mais do que um conceito de programação, ela representa uma forma bastante natural de o cérebro humano interagir com o ambiente. Quando entramos em uma sala, por exemplo, naturalmente identificamos coisas com características semelhantes e as agrupamos mentalmente: reconhecemos cadeiras, mesas, pessoas, portas etc. Intuitivamente, estamos classificando elementos em categorias (classes) e identificando suas ocorrências concretas (objetos). A POO utiliza justamente essa maneira de pensar para representar o mundo dentro de um sistema, considerando que os objetos possuem estado e comportamento.

A história da POO começou antes do próprio Java, passando por linguagens como Simula e Smalltalk, que ajudaram a estabelecer conceitos fundamentais desse paradigma. Posteriormente, linguagens como C++ e Java popularizaram a orientação a objetos no desenvolvimento de software.

Em Java, uma classe funciona como um modelo para criar objetos. Ela define seus atributos, que representam o estado, e seus métodos, que representam os comportamentos. A partir de uma classe Car, por exemplo, podemos criar vários carros diferentes, cada um com seu próprio estado.

A criação de um objeto é feita normalmente através do operador new, como em Car myCar = new Car();. Nesse momento, estamos criando uma instância concreta da classe. Os construtores são utilizados para inicializar esses objetos e possuem o mesmo nome da classe, não tendo tipo de retorno.

Outro conceito importante são as interfaces, que funcionam como contratos de comportamento. Uma interface pode definir operações que uma classe deve implementar, permitindo que diferentes tipos de objetos sigam o mesmo contrato. Além disso, Java possui membros static, que pertencem à própria classe e não a uma instância específica.

Também existem os initializer blocks, que permitem executar código durante a inicialização de objetos ou durante o carregamento da classe. Embora sejam recursos menos utilizados no dia a dia, fazem parte dos mecanismos de inicialização disponíveis em Java.

Esses conceitos formam a base para compreender os pilares mais avançados da POO: encapsulamento, herança, polimorfismo, abstração e composição. A partir deles, conseguimos construir sistemas mais organizados, reutilizáveis e fáceis de manter — e é justamente sobre esses conceitos que o estudo de POO em Java deve avançar.