バックエンドAPIのソフトウェアアーキテクチャ - slcsol4/wyn-wiki GitHub Wiki

概要図

image

ソフトウェアアーキテクチャについて

クリーンアーキテクチャを目指す
各レイヤーに属するモジュールの責務を単一責任の原則に従って分類わけしやすくするため、当レイヤーでの管理を採用する ールの責務を単一責任の原則に従って分類わけしやすくするため、当レイヤーでの管理を採用する

各レイヤーの説明・責務の分類

各レイヤーの説明および責務を記載する

～Out Side～

  • 外界
  • サービス・DB・UIなど

～External Interface～

  • 外界との相互作用を担当する層
  • 業務ロジックは実装しない

api-core層（今回は利用しない）

  • Out Side(クライアント)とのI/Fを担当する
  • Restのルールに従って受け付けたリクエストを受け付けてcontrollerに引き渡す
    • 認証・認可情報の処理を行う
  • 責務
    • apiのインタフェース

db-lib層

  • データベースへのアクセスを管理する
  • テーブルと１対１でclassが存在すると考えて相違ない
  • アクセスのためのEntityをもつ
  • メソッド種は主に以下の通り
    • findBy ・・・ 主キー検索（entityを返す）
    • selectBy ・・・ 条件検索（Listのentityを返す）
    • insert ・・・ 登録(entityを登録する)
    • delete ・・・ 削除(entityを削除する)
    • update ・・・ 更新(entityを更新する)
  • 責務
    • findBy, selectBy
      • DBの内容をentity化し、返却する
    • insert, delete, update
      • entityをDBに反映する

～Interface Adaptor～

  • API内部と外部のデータ変換を行う

contoroller層

  • 業務ロジックを組み合わせて業務を実現する
  • request-model・response-modelをもつものもある
  • 責務
    • GET系
      • response-modelを作成して返却する
        • domain-model → response-modelへの変換を行う
    • PUT・POST・DELETE系
      • 依頼内容に応じた業務処理を実施する

～Use case～

usecase層

  • 業務ロジックを担当する
  • 責務
    • Factory
      • domain-modelと一対一の関係をもつ
      • 完全なdomail-modelを作成する（完全でないといけない。一部の情報が欠けているのはNG）
        • entity→domain-modelへの変換を行う
    • Repository
      • domain-modelを永続化する（登録・更新・削除）
        • dmain-model→entityへの変換を行う
    • Service
      • domain-modelの妥当性を検証する

～Domain～

model層

  • アプリケーションのデータ構造（domain-model）を管理する
  • 責務
    • データ構造を管理する
⚠️ **GitHub.com Fallback** ⚠️