Enterprise Integration Patterns

Enterprise Integration Patterns, or EIP, is a technology-independent pattern language for message-based integration. Cohesive uses the catalog as an important architecture vocabulary while preserving the distinction among domain semantics, system-graph structure, operational concerns, architecture practices, and realization substrate.

An EIP pattern is not automatically a Cohesive semantic primitive. A pattern may instead:

Carry a semantic value or intended interpretation in a message.
Arrange messages, channels, routes, endpoints, or flow operators in the system graph.
Require delivery, ordering, compatibility, correlation, retention, or recovery guarantees.
Realize an interaction through a broker, file exchange, database, application host, or network protocol.
Compose several lower-level structures and guarantees into an architecture practice.

Foundational Correspondence

Message emission and ingress are occurrences. At a receiving boundary, message ingress is an exogenous event carrying a value. A message contract may explicitly express singular command intent, report an occurrence, transfer a document, request a reply, or signal another protocol role. That contract supplies strong evidence for interpretation without replacing the receiving observer that admits and interprets the input.

The transport medium remains distinct from the semantic construct while maintaining an explicit correspondence. A channel or broker realizes delivery; a message carries a value and contract; an observer interprets the received occurrence; a transition or process determines the resulting semantic work.

Later Control-Flow Extension

The original EIP catalog mainly depicts the data flow of messages through endpoints, channels, routers, and transformers. Gregor Hohpe's later control-flow extension adds a second, orthogonal question: which element actively drives each interaction? Cohesive represents this as interaction control flow.

The extension distinguishes active senders and fetchers from passive sinks and sources. Applying those roles independently to both ports of a stage yields pushers, pullers, queues, and drivers. A queue accepts an active producer on one side and serves an active fetcher on the other, separating arrival cadence from departure cadence. A driver actively fetches and pushes, giving it direct control over polling, batching, and rate.

This is not a sixty-sixth peer pattern or a new semantic primitive. It is a cross-cutting operational facet of the original patterns, especially Pipes and Filters, Message Channel, Polling Consumer, Event-Driven Consumer, Competing Consumers, and broker-backed routing. A pattern diagram should state whether each arrow depicts message or data movement, interaction control, causal order, or process progression because those directions can differ.

Realm Orientation and Domain Reconciliation

EIP patterns tend to gravitate toward System Graph, Operational Concerns, and Realization Substrate. They are strongest at describing carriers, paths, endpoints, transformations, routing, delivery arrangements, and management structures. DDD gravitates toward Domain Semantics and the architecture practices that preserve semantic boundaries, authority, invariants, and ubiquitous language.

The two vocabularies meet through explicit correspondence rather than identification:

EIP construct	Semantic reconciliation
Command Message	A carrier whose contract strongly indicates command intent; ingress remains an exogenous event and command interpretation remains relative to the receiving observer.
Event Message	A carrier reporting an occurrence; the reported domain event and the message-receipt event are distinct occurrences at different boundaries.
Message Channel	An interaction locus that does not decide the semantic role, authority, or business completion meaning of what it carries.
Process Manager	A routing and coordination pattern that may realize part of a semantic process but does not define its purpose, state authority, recovery policy, or terminal outcomes.
Canonical Data Model	A selected integration representation that does not become canonical domain meaning or one enterprise-wide ubiquitous language.

The realm correspondence framework starts with the DDD meaning and boundary, places that meaning into messages, channels, observers, effects, and process graphs, assigns EIP structures and operational obligations, and only then selects a broker, runtime, store, protocol, or file exchange.

Catalog Coverage

Integration Styles

EIP pattern	Cohesive correspondence
File Transfer	batch and file exchange, interaction, and storage systems
Shared Database	storage systems, shared-state interaction, boundaries, and isolation
Remote Procedure Invocation	request/reply, network, and application hosts
Messaging	interaction, messages and envelopes, interaction channels, and brokers

Messaging Systems

EIP pattern	Cohesive correspondence
Message Channel	interaction channels and interaction control flow
Message	messages and envelopes
Pipes and Filters	flow operators, flow views, and interaction control flow
Message Router	routing models
Message Translator	anti-corruption layer and compatibility and evolution
Message Endpoint	observer models and ports and adapters

Messaging Channels

EIP pattern	Cohesive correspondence
Point-to-Point Channel	interaction channels and consumer coordination
Publish-Subscribe Channel	interaction channels and brokers
Datatype Channel	interaction channels, shape, and compatibility and evolution
Invalid Message Channel	retention, expiration, and quarantine and recovery
Dead Letter Channel	retention, expiration, and quarantine and asynchronous interaction design
Guaranteed Delivery	delivery semantics, durability, and acknowledgments
Channel Adapter	ports and adapters and realization
Messaging Bridge	interaction channels, brokers, and network
Message Bus	interaction channels, brokers, and infrastructure graph

Message Construction

EIP pattern	Cohesive correspondence
Command Message	messages and envelopes carrying explicit command intent as an exogenous event at ingress
Document Message	messages and envelopes carrying an observation, state transfer, artifact, or other shaped value
Event Message	messages and envelopes carrying a reported occurrence; receipt is also an exogenous messaging event
Request-Reply	request/reply, request effects, and correlation and conversations
Return Address	correlation and conversations and interaction
Correlation Identifier	correlation and conversations, identity, and causality
Message Sequence	correlation and conversations and ordering
Message Expiration	retention, expiration, and quarantine and time
Format Indicator	compatibility and evolution, version, and shape

Message Routing

EIP pattern	Cohesive correspondence
Content-Based Router	routing models and policy scopes
Message Filter	flow operators and policy scopes
Dynamic Router	routing models, observer models, and routing observations
Recipient List	routing models and interaction channels
Splitter	flow operators
Aggregator	flow operators, correlation and conversations, and consistent cuts
Resequencer	flow operators and ordering
Composed Message Processor	flow operators, flow views, and compositionality
Scatter-Gather	flow operators, request/reply, and correlation and conversations
Routing Slip	routing models and process graphs
Process Manager	process managers and process graphs
Message Broker	routing models and brokers

Message Transformation

EIP pattern	Cohesive correspondence
Envelope Wrapper	messages and envelopes
Content Enricher	flow operators, observations, and projection models
Content Filter	flow operators, shape, and boundary-relative projection or redaction
Claim Check	messages and envelopes, identity, and storage systems
Normalizer	anti-corruption layer and compatibility and evolution
Canonical Data Model	anti-corruption layer, compatibility and evolution, and system language and realization

Messaging Endpoints

EIP pattern	Cohesive correspondence
Messaging Gateway	ports and adapters, observer models, and application hosts
Messaging Mapper	ports and adapters, shape, and realization
Transactional Client	commit boundaries, ACID, transactional outbox, and transactional inbox
Polling Consumer	consumer coordination, interaction control flow, scheduling, and interaction
Event-Driven Consumer	consumer coordination, interaction control flow, observer models, and runtimes
Competing Consumers	consumer coordination, arbitration, and fairness
Message Dispatcher	consumer coordination and routing models
Selective Consumer	consumer coordination, routing models, and policy scopes
Durable Subscriber	consumer coordination, durability, and retention, expiration, and quarantine
Idempotent Receiver	idempotency and transactional inbox
Service Activator	ports and adapters, observer models, and application hosts

System Management

EIP pattern	Cohesive correspondence
Control Bus	operational control and infrastructure graph
Detour	operational control, routing models, and policy scopes
Wire Tap	observability and provenance
Message History	observability and provenance and causality
Message Store	observability and provenance, persistence, and storage systems
Smart Proxy	correlation and conversations, routing models, and interaction
Test Message	operational control and observability and provenance
Channel Purger	operational control and retention, expiration, and quarantine

Boundary of Adoption

Cohesive encompasses these patterns by making their semantic inputs, structural arrangements, operational guarantees, and realization choices explicit. It does not preserve assumptions that no longer hold. In particular, guaranteed delivery is not business completion, a canonical integration model is not canonical domain meaning, and a process manager is not the semantic process it coordinates.

External References

Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley Professional, 2003.
Enterprise Integration Patterns, Messaging Patterns Overview and Table of Contents.
Gregor Hohpe, Control Flow—The Other Half of Integration Patterns, 2024.