skillup

技術ブログ

プログラミング全般

アプリケーション間のデータの連携方法に関して

投稿日:

以前やった「現場で役立つシステム設計の原則」を再読してます。

今、読んでいるのはアプリ間のデータ連携に関して。

複数のアプリ間でデータをやり取りする場合、以下のような方法が考えられます。

  • ファイルを直接渡す(CSVなど)
  • データベースを共有する
  • APIでつなぐ
  • メッセージングで渡す

ちょっとそれぞれのメリット、デメリットを見ていこうかと。

ファイルを直接渡す

CSVファイルなどをダウンロードしたりするパターンです。一般的には定期バッチなどで他システムにデータを送ることが多いかと思われます。

メリット

  • 連携に関する工数がかからず簡便

デメリット

  • 受け取る側が基本的に加工することが前提
  • 単純なデータの型(CSV)タイプでないと送りにくい
  • CSVデータと実データで差分ができるケースがあり

データベースを共有

内部システムのデータ連携などによく使われるパターンです。サブシステムなどから連携するときはこのパターンが多いでしょう。

メリット

  • データを受け取る側がある程度自由にデータを取得できる(リレーションなど)
  • 直接データを見るパターンになり、データの差分がない

デメリット

  • 不特定多数のユーザーには使えず、内部システム限定
  • 結合度が強くなりがち(参照するテーブルの変更の影響を受ける)
  • 接続を可能にするための権限の設定など要考慮

API

一般的にはRESTAPIのことをさすことが多く、データ連携で一般的に使われるパターンです。

メリット

  • 受け渡すデータの形を制限することができる
  • 内部設計の影響の依存度の影響を抑えることができる
  • 不特定多数への公開が可能
  • 参照だけでなく、更新作業や削除も可能

デメリット

  • 受け渡す側での設計考慮が必要
  • 同期型になるため、運用面で制約を受けることあり
  • 開発時のコミニケーションや連携などをうまくしないと遅延が発生する

メッセージング

テーブルか他のキューシステムなどを作り、非同期にデータ連携をするパターンです。

メリット

  • 非同期処理に有効
  • 比較的依存度が小さくなることが多い

デメリット

  • 同期型の処理はできない
  • データ差分に注意

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

emptyの扱いに関して

PHPで空白や存在確認として便利なemptyですが、乱用すると意図しない動きをすることがあるケースが多々あります。 Contents1 emptyの挙動に関して2 数値の03 検索などの全判定と値のな …

no image

コードの抽象化

リーダブルコードも終盤に少しずつ近づいてきました。 今まではどちらかというとコードの点や線の技術に注目してきましたが、これからは面的な要素に注目していきます。 リーダブルコードでは「無関係の下位問題を …

no image

トークン認証に関して

Contents1 トークンでの認証2 Laravelでのtoken トークンでの認証 APIアプリケーションを作る場合、認証方式としてはクッキーとセッションを利用したものよりもトークンを使った認証方 …

no image

短いコードを書く

私が普段コードを書くときに考えていることは常にいかに短くかけるか、ということといかにバグを生み出さないかということです。 基本的にはできるだけ、短くシンプルに書くようにしています。 そうすることであと …

no image

例外処理に関して

いまいち使い方がいい加減だった例外処理について、復習がてらメモします。 昔のリンクを整理して出てきた例外リンクはこちら(Javaですが今のPHPにも当てはまるかと思います。) 例外処理について 例外処 …