実践クリーンアーキテクチャに行ってきた #narusemi

実践クリーンアーキテクチャに参加しました。今回はオンライン開催。簡単に所感をまとめます。

nrs-seminar.connpass.com

所感

JJUG CCC 2019 Spring の再演。このセッションは参加してなかったのでこの機会に聴けてよかったです。先月、ドメイン駆動設計入門を読み終わったところなのでより理解が深められた気がする。

クリーンアーキテクチャは確かに定義するファイルが多くなりがちみたいだけど、それぞれがどういう役割を担っているか、特にクリーンアーキテクチャの図で右下の図がどういうことを表しているのかが理解できました。あと、課題に対してどういうアプローチを取るか、そのあたりの話は参考になります。

とはいえ、クリーンアーキテクチャを知らなくてもインタフェースの役割が理解できていれば、ある程度は近しい形というか同じような目的を実現する仕組みにはなるのかなって思ったり。ただまぁ、そのあたりの共通認識になるものとしてアーキテクチャとして提言されてるんでしょうけど。

次回はフロントエンド寄りの話らしいです。期待。

以下、メモから抜粋。

先行開発！クリーンアーキテクチャ -- ゼロから始める新規開発

https://youtu.be/5oJeSrwztPgyoutu.be

• 最終形に辿り着くために試行錯誤したい
  • フロントのプロトタイプを作りたい
  • クリティカルパスを避けて先行開発したい
• クリーンアーキテクチャ
• 先にヘキサゴナルアーキテクチャを学ぶのがおすすめ☆
  • 交換可能 (プラガブル)
  • ポート&アダプタ
  • アプリを中心に置く
  • アプリ (ビジネスロジック) は入力デバイスやデータストアのことは知らない☆
  • ビジネスロジックを点在させない☆
• クリーンアーキテクチャ
  • やりたいことはヘキサゴナルアーキテクチャと同じ
  • 外側の具体的な実装について言及しているのがクリーンアーキテクチャ☆
  • ※オニオンアーキテクチャは内側のフォーカスしたもの
• SOLID原則
• Entities (Enterprise Business Rules)
  • ドメインモデルを実装したドメインオブジェクト
• Use Cases (Application Business Rules)
  • アプリケーションレイヤ
  • ドメインオブジェクトを束ねてユースケースを実現する
• Controllers, Presenters, Gateways (Interface Adapters)
  • Use Case Interactor
  • Use Case Input Port / Output Port (interface)
• Frameworks & Drivers
  • ビジネスロジックはこれに依存しないように
  • 実装の詳細がビジネスロジックに出ないように
    • HTTP, UI, ...
  • フレームワーク移行でビジネスロジックに影響しないか☆
  • フレームワークがドメインロジックに依存する
• 依存の方向を内向きにする
  • Web, DB, UI, ...
  • フレームワーク移行、モジュール差し替え、テスト、...
• Controller
  • アプリが要求するデータに入力を変換する
  • Input Data に変換する
• Input Data / Output Data / View Model
  • Data Structure (データ構造体)
  • DTO (POJO)
• Input Boundary (interface)
  • Input Port
  • ユースケースごとに interface を分ける
• Use Case Interactor
  • Input Boundary の実装
  • アプリケーションロジック
  • Input Data を受け取って処理して Output Data を返す
• Data Access Interface (interface)
  • Repository
  • データにアクセスするためのインタフェース
  • クリーンアーキテクチャの Gateways
• Data Access
  • Entity のオブジェクトを再構築する
  • 実装は何でもOK (SQL, ORM, Mock, ...)
• Entities
  • ビジネスロジックのオブジェクト
  • ドメインオブジェクト
  • データモデルとは異なる☆
• Output Boundary (interface)
  • Presenter のインタフェース
  • 出力データを渡すためのインタフェース
• Presenter
  • Output Boundary の実装
  • Output Data から View Model に変換する
  • View Model を View に引き渡す
• 処理の流れ☆
• フロントを先行開発したい
  • クリーンアーキテクチャをどう使うか
  • ユースケースのスタブを用意する
  • 例外時の動作確認がやりやすい
• Web アプリのフレームワークでは Controller でレスポンスが必要
  • Presenter と相性がわるい
  • ネイティブアプリの場合は Presenter は相性がいい？
    • iOS / Android で変えられるから
  • ⇒ Presenter を捨てる
  • ⇒ Output Data をそのまま返す
  • ⇒ Output Data を Boundary に渡すか、戻り値で返すかの違いだけ
  • Output Data に変換してるからビジネスロジックに依存していないはず☆
  • Output Data ⇒ View Model の変換は Controller が担う
• アクションごとにユースケースがある
  • Controller のフィールドが多くなりがち (@Inject Hell)
  • ユースケースが増えるたびに Controller の修正が必要
  • ⇒ Message Bus (UseCaseBus)
  • ⇒ Command オブジェクト
  • Input Data から期待する Output Data は分かる
  • 処理の実体 (Interactor) は何でもOK
• 定義するものが多い (作るファイルが多い)
  • ⇒ 自動生成ツール
  • モジュール / テストモジュール / テストデータ / DI 設定
  • 同名の JSON ファイルから Output Data を構築するスタブ
  • BFF とかだと特に便利
• 依存関係逆転の原則☆
• ビジネスを中心にシステムを組み立てる☆
• https://github.com/nrslib/play-clean-java