データ詰め替えの戦略 に行ってきた #アーキ部

メモ

データ詰め替えの戦略に参加しました。簡単に所感をまとめます。

architect-club.connpass.com

所感

データ詰め替えの話が気が付いたらモデリングの話になってました。自分がこれまでよく見たのは Two-way mapping ですかね。あと、ドメインモデルを UI 層にマッピングするのもあった気がする。

レイヤではなく、Tier や距離という考え方はこれまで意識したことがなかったので参考になりました。

結合度や距離によってデータ詰め替えのパターンを選択するのがいいのかなと思いました。それらをあまり考えずにどちらかに寄せすぎると、過剰な詰め替えが発生したり、距離が遠いのにモデルを共有してしまって密結合になったりするのかなと。要はバランスおじさん。

アーキ部は数えるくらいしか参加したことないけどとても勉強になります。ちなみに最近はこんな本を読んでます。

www.shoeisha.co.jp

以下、メモから抜粋。

  • 元ネタ: Clean Architecture with Spring Boot | Baeldung
  • One-way mapping は使わない方がいい
  • No mapping
  • Two-way mapping
    • Web Model (Form/View Model) ↔ Domain Model ↔ Persistence Model (Entity (OR mapper))
  • Full mapping
    • レイヤ間で Update Command に詰め替えて受け渡す
    • 疎結合を忠実に守ると Full mapping になりがち
  • Terasoluna
    • Form ↔ Entity (≒ Domain Model)
  • Domain Modeling Made Functional
    • I/O 側のモデルを切り離す (DTO ↔ Domain ↔ Update Command)
  • ドメインモデルとデータアクセス層のモデル共有
    • ドメインモデルがテーブル設計の質に依存する
    • テーブル変更がドメインモデルに影響する
      • これが問題になるならモデル共有はしない方がいい
  • ドメインモデルとプレゼンテーション層のモデル共有
    • Tier
    • LayerとTierの違い - kawasima
    • 同じ Tier で HTML に出力する場合はプレゼンテーションモデルを作らずドメインモデルを参照する
    • ドメインモデルを FE に返すと機密情報が漏洩する可能性あり
    • Tier が分かれる = 距離が遠い = 共有しない方がいい
  • DTO
  • 結合強度
    • 侵犯結合
    • 機能結合
    • モデル結合 (モジュール間でモデルを共有する)
    • 契約結合 (モジュール間でモデルを共有しない)
  • モジュールの距離
    • 変更するコンポーネントの距離が遠くなるほど変更の労力は大きくなる
    • 結合強度が強いものは距離が近いところに置く (≒ 高凝集)
    • 結合強度が弱いものは距離が遠いところに置く (≒ 疎結合)
    • 同じ Knowledge を共有する = 同時に変更することになりがち = 結合強度が強い
  • テーブルに項目追加するとドメインモデルに影響する → バランスが取れていないケース
  • モデルの共有 ≠ コードの共有 → Knowledge を共有しているかどうか
    • コード/モデルを分離しても知識が共有されていると同時に変更が必要になりがち
  • データ/情報
    • 情報はデータに解釈を加えたもの
    • データは解釈によって別の意味になる
    • 情報を区別するには → 構造を変える or 名前を変える
  • データモデル/ドメインモデル
    • テーブルファースト → ドメインモデルファーストのアプローチ
  • モデルを分けるとマッピングする意味が出てくる
  • 解釈は多層的
    • DB テーブルレベルでの解釈
    • アプリケーションレベルでの解釈 (汎用的な解釈)
    • ユースケースに沿った解釈
    • 多層的な解釈がないならモデルを共有して距離を近くする方がいい
  • データの解釈を型で表現する
  • 解釈を加えたドメインモデルにマッピングする場合、データアクセス層のインターフェースはどうなるか