Tyler-R-Kendrick

integration-patterns

Use when designing or evaluating enterprise integration architectures based on Hohpe & Woolf's Enterprise Integration Patterns. USE FOR: Enterprise Integration Patterns, messaging architecture, choosing integration patterns, pipes and filters, message-oriented middleware DO NOT USE FOR: specific pattern implementations in code (use sub-skills), API design (use dev/backend/api-design), event sourcing (use dev/architecture/event-driven)

Tyler-R-Kendrick 10 3 Updated 3mo ago

Resources

6
GitHub

Install

npx skillscat add tyler-r-kendrick/agent-skills/integration-patterns

Install via the SkillsCat registry.

SKILL.md

Enterprise Integration Patterns

Overview

Enterprise Integration Patterns (EIP), catalogued by Gregor Hohpe and Bobby Woolf, define a vocabulary of 65 patterns for designing robust, asynchronous messaging systems. The patterns describe how to connect applications, transform data in flight, route messages intelligently, and manage messaging infrastructure -- all while keeping systems loosely coupled and independently deployable.

The book organises patterns around the pipes-and-filters architectural style: messages flow through a series of processing steps (filters) connected by channels (pipes).

Pattern Categories

┌─────────────────────────────────────────────────────────────────┐
│                   Enterprise Integration Patterns               │
├───────────────┬───────────────┬───────────────┬─────────────────┤
│  Messaging    │  Message      │  Message      │  Message        │
│  Channels     │  Construction │  Routing      │  Transformation │
│               │               │               │                 │
│  How messages │  How messages │  How messages  │  How messages   │
│  travel       │  are built    │  are directed │  are reshaped   │
├───────────────┴───────────────┴───────────────┴─────────────────┤
│  Messaging Endpoints          │  System Management              │
│                               │                                 │
│  How applications connect     │  How to monitor, test, and      │
│  to the messaging system      │  control the messaging system   │
└───────────────────────────────┴─────────────────────────────────┘

Pipes-and-Filters Architecture

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  Source   │───>│ Filter A │───>│ Filter B │───>│  Sink    │
│ (Producer)│    │(Transform│    │ (Route)  │    │(Consumer)│
└──────────┘    └──────────┘    └──────────┘    └──────────┘
      pipe           pipe           pipe
    (channel)      (channel)      (channel)

Each filter performs a single processing step (validate, enrich, transform, route). Each pipe is a message channel connecting one filter to the next. This architecture provides:

  • Composability -- combine simple filters into complex workflows.
  • Replaceability -- swap a filter without touching others.
  • Scalability -- scale individual filters independently.
  • Testability -- test each filter in isolation.

When to Use Messaging vs. Direct Calls

Concern Direct / Synchronous Calls Messaging / Asynchronous
Coupling Caller must know callee's address and API Sender only knows the channel
Availability Callee must be running Callee can be offline; messages queue
Latency Immediate response required Eventual response acceptable
Throughput Limited by slowest participant Buffer with queues; scale consumers
Error handling Caller handles errors in real time Dead-letter channels, retries, compensation
Complexity Simple for 1:1 interactions Worth it when >2 participants or reliability matters

Rule of thumb: Start synchronous. Move to messaging when you need temporal decoupling, load levelling, reliable delivery, or fan-out to multiple consumers.

Pattern Selection Guide

Problem Pattern Category Key Patterns
How do I send a message from A to B? Messaging Channels Point-to-Point Channel, Channel Adapter
How do I notify many subscribers? Messaging Channels Publish-Subscribe Channel
What goes inside a message? Message Construction Command Message, Event Message, Document Message
How do I correlate request and reply? Message Construction Correlation Identifier, Return Address
How do I route to the right consumer? Message Routing Content-Based Router, Recipient List
How do I split and reassemble? Message Routing Splitter, Aggregator
How do I orchestrate a multi-step flow? Message Routing Process Manager, Routing Slip
How do I reshape data between systems? Message Transformation Content Enricher, Normalizer, Canonical Data Model
How do I reduce message size? Message Transformation Claim Check, Content Filter
How do I consume messages reliably? Messaging Endpoints Competing Consumers, Idempotent Receiver
How do I monitor and debug? System Management Wire Tap, Message Store, Control Bus

Reference Implementations

Technology Language / Platform Strengths
Apache Camel Java / JVM Broadest connector ecosystem; DSL routes map 1:1 to EIP
Spring Integration Java / Spring Deep Spring ecosystem integration; annotation-driven
MassTransit C# / .NET First-class saga support; RabbitMQ & Azure Service Bus transports
NServiceBus C# / .NET Commercial-grade; strong tooling and monitoring
MediatR C# / .NET In-process mediator; great for CQRS without infrastructure
Azure Service Bus Cloud (Azure) Managed broker; topics, subscriptions, sessions
RabbitMQ Any (AMQP) Lightweight broker; exchanges map to routing patterns
Apache Kafka Any Log-based streaming; high throughput; replay capability

Best Practices

  • Learn the pattern language before choosing a framework -- the vocabulary transcends any single implementation.
  • Prefer idempotent message handlers; at-least-once delivery is the norm.
  • Design messages as immutable, self-describing contracts with schema versioning.
  • Keep channels focused on a single data type or purpose (Datatype Channel).
  • Use Dead Letter Channels for every queue -- never silently drop messages.
  • Instrument messaging with Wire Taps and Message Stores from day one; debugging async flows without observability is painful.
  • Start with the simplest topology (point-to-point) and evolve toward pub-sub or content-based routing only when the need is proven.