skillup

技術ブログ

アーキテクト設計全般

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

投稿日:2020年10月18日 更新日:

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

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

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

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

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

ファイルを直接渡す

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

メリット

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

デメリット

  • 受け取る側が基本的に加工することが前提
  • 単純なデータの型(CSV)タイプでないと送りにくい
  • ファイル形式の変更などの場合、影響が大きい
  • CSVデータと実データで差分ができるケースがあり(リアルタイム性が弱い)

データベースを共有

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

メリット

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

デメリット

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

API

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

メリット

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

デメリット

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

メッセージング

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

メリット

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

デメリット

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

-アーキテクト設計全般
-

執筆者:


comment

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

関連記事

no image

DIについての再考察

DIに関しては今までも何度か触れましたが、最終的には環境の差異を吸収できるなどが一番のポイントかと。 サンプルソース https://github.com/umanari145/effector 上記 …

no image

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

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

no image

Facadeパターンについて(Laravelを題材に)

LaravelのFacadeについて自作する機会があったので、メモ。 Contents1 サンプル2 使い所3 メリット4 デメリット5 参考リンク サンプル https://github.com/u …

no image

オブジェクト指向 アプリケーション層に関して

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。 Contents1 …

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

アーカイブ