Integration Pattern

Origin & evolution

Gregor Hohpe and Bobby Woolf gave the field its vocabulary in Enterprise Integration Patterns (2003), a pattern language of 65 patterns for message-oriented middleware. Before the detailed patterns, they framed four integration styles that still organise the decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →:

• File Transfer has each application produce files for others to consume. Simple and universal, weakest on timeliness.
• Shared Database has applications read and write a common store. Strong consistency, tight coupling through the schema.
• Remote Procedure Invocation has each application expose procedures others call directly. Immediate and familiar, but synchronous and brittle under partial failure.
• Messaging✉️MessagingGo-To-MarketMessaging framework and key messagesView reference → has applications exchange data through a common messaging system. Decoupled and asynchronous, at the cost of more moving parts.

Hohpe and Woolf argued the messaging style resolves the trade-offs the other three force, and the bulk of their book elaborates it. The topology question sits alongside the style: point-to-point connections multiply links as systems grow (the n-squared problem); a hub-and-spoke or message broker centralises routing; an event bus lets producers and consumers join without knowing each other. Microservices and event-driven architecture have since made messaging and the event bus the default for new systems, while RPC reappeared as REST and gRPC.

How it works in practice

A retailer connects its warehouse, storefront, and finance systems. Nightly stock reconciliation moves a large batch with no urgency, so it stays a File Transfer: a CSV dropped to a shared location each midnight. Order placement needs🫀NeedUserA user need, pain, desire, or constraintView reference → every system to react within seconds, so it runs over Messaging through a broker, where the storefront publishes an event and warehouse and finance subscribe independently. The team rejects a Shared Database for orders, because coupling three systems to one schema would mean every change negotiated three ways. Two patterns coexist by design, each matched to its timeliness and coupling needs.

Integration pattern vs. its neighbours

• External API🌐External APIEngineeringAn external API consumed by the productView reference → is one concrete interface you connect to. An integration pattern is the style of that connection; the same external API might be reached by RPC today and wrapped behind messaging tomorrow without the API itself changing.
• Queue topic📬Queue TopicEngineeringA message queue topicView reference → is a specific channel within the messaging style. An integration pattern is the wider category; choosing messaging is the pattern decision, and a topic is one mechanism that realises it.
• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference → is a boundary in the domain with its own model and language. An integration pattern is how two bounded contexts talk across that boundary; the boundary motivates the integration, and the pattern determines how cleanly the two models stay separated.

In the graph

In the Unified Product Graph, integration_pattern🔗Integration PatternEngineeringAn integration pattern (saga, event sourcing, etc.) is a leaf in the Engineering & Platform region. Two hierarchy edges anchor it: product_integrates_via_integration_patternProductintegrates viaIntegration Patternhierarchy records the styles a product relies on, and bounded_context_integrates_via_integration_patternBounded Contextintegrates viaIntegration Patternhierarchy localises a style to the boundary it serves. Modelling the pattern as its own entity, distinct from the APIs and topics that implement it, lets a team read its integration strategy directly: which boundaries lean on synchronous calls, which on messaging, and where a default choice quietly set the coupling that a later change will have to pay for.