複数のシステム(やサービス)を跨いでデータ連携したい、なんて要望は今やどこの現場でもあると思うが、その際のデザインとしてEnterprise Integration Patternというものがある。この手の検討は主に「方式設計」なんて呼ばれていて、開発のかなり早い段階で検討されたりする。Enterprise Integration Patternには4パターンあり各々簡単にまとめた。
パターン1：File Transfer
いわゆるファイル転送でのデータ連携。比較的容易に実現出来て、色んな現場で見かけるパターン。即時性を求められないバッチ等でよく見受けられる。双方のシステムで連携するデータ項目を定めて、IFファイル定義書を作成する。
パターン2：Shared Database
いわゆるデータベース共有でのデータ連携。説明不要ってくらいどこにでもあるデータ連携方式。フロントエンドとバックエンドで分かれるようなシステム構成をとる場合によく利用される。
パターン3：Remote Procedure Invocation
RESTやSOAPみたいなWeb APIなんかはこのパターン。外部システムのProcedureをリモートコールしてデータ連携する。昔はSOAでSOAP、最近ではマイクロサービスアーキテクチャなんかが注目されてきて特にRESTful APIなんかはトレンド感がある。
パターン4：Messaging
メッセージバスと呼ばれる、非同期を前提としたフレームワークを介してデータ連携するパターン。SOAなんかでは多く見られたパターン。
どのパターンを採用するか？
最近マイクロサービスアーキテクチャという言葉をよく聞くからといって、安易にパターン3のRemote Procedure Invocationパターンを使おう！ではだめです。また、リアルタイム性が求められているのにパターン1のFile Transferやパターン4のMessagingを使うのも違うかと思います。自分たちが何を求めているのかしっかりと分析したうえで、じゃあこれだね、ってなるかと思います。要するに適材適所です。