skillup

技術ブログ

プログラミング全般

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

投稿日:

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

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

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

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

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

ファイルを直接渡す

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

メリット

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

デメリット

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

データベースを共有

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

メリット

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

デメリット

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

API

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

メリット

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

デメリット

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

メッセージング

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

メリット

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

デメリット

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

-プログラミング全般
-

執筆者:


comment

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

関連記事

no image

DIとDIコンテナについて再考

今までも何度かやったDI(Dependency Injection = 依存性の注入)について。 以前のリンク PHPにおけるDI スコープアノテーションとCDIについて Contents1 DIとは …

no image

オブジェクト指向 データベース層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にデータベース層の考え方について。 Contents1 データべース層1.1 要点1.1.1 典型的なダメテーブル設計1.1 …

no image

テストコードの考え方

一般的なプログラマにとって日々の業務で何がいやかというと、 理不尽な納期 むちゃくちゃな仕様変更 頻発するバグ・不具合 であることは異論がないでしょう。仕様変更や納期などは自分で何とかしがたい部分もあ …

no image

エラーレポーティングサービス Sentryについて

リリースした後、運用段階に入ると定期的にバグ報告が上がってきます。 本来はリリース前に研修テストをすべきなんですが、そんな余裕ないことも多い(汗) で、そんな時に大事なのが エラーを気づけること 対処 …

no image

ログインしたままにするの挙動に関して(ステートフル認証の基本的な仕組みの復習もかねて)

基礎の基礎ですが、ログイン処理に関しての動きに関して。 Contents1 通常のログイン処理に関して2 ログインしたままにする 通常のログイン処理に関して 通常のログイン処理では、まず以下のような手 …

アーカイブ