ツールで防衛 クリーンアーキテクチャ / CleanArchitecture

動画: https://www.youtube.com/watch?v=btJPK3TaJMg&feature=youtu.be&t=10830

2018/09/01 大阪にて行われたプログラミング生放送勉強会でのプレゼンです。
クリーンアーキテクチャの実装についての解説をメインにしています。

資料中に出てくる URL

# 著者ホームページ
https://nrslib.com/

# このスライドを元にした解説
https://nrslib.com/practice-of-clean-architecture/
# サンプル
https://github.com/nrslib/PracticeOfCleanArchitecture

Transcript

1. ツールで防衛
   クリーンアーキテクチャ
   成瀬 允宣
   Masanobu Naruse
   2018/9/1 プログラミング生放送 第53回@大阪
   1
   

   View Slide

2. 自己紹介
   • 成瀬 允宣 - Masanobu Naruse
   • GMOインターネット（システム本部 UXデザイン開発部）
   • プログラマ
   • C# , Typescript, Scala
   • DDD とかアーキテクチャの話が好きです
   • @nrslib
   • https://nrslib.com/
   2
   

   View Slide

3. セッションの目的 3
   クリーンアーキテクチャ
   を
   実践できるようになる
   

   View Slide

4. もくじ
   • 直近の苦労話
   • 何が問題だったのか
   • 思い描いた夢
   • クリーンアーキテクチャ
   • 立ちはだかる現実
   • アーキテクチャのための冗長化に対する解決方法
   • 最後に
   4
   

   View Slide

5. 直近の辛かったプロジェクト 5
   前任者無し
   仕様書無し
   頼れる仲間はベトナムへ
   

   View Slide

6. 前任者無し 6
   前任者が退職
   

   View Slide

7. 前任者無し 7
   前任者が退職
   将来利用される予定のコード
   現在利用されているコード
   混在
   

   View Slide

8. 仕様書無し 8
   どういう入力をすると
   どういう出力が返ってくるか
   わからない
   

   View Slide

9. 仕様書無し 9
   どういう入力をすると
   どういう出力が返ってくるか
   わからない
   というかそもそも
   どういう入力をすればいいのか
   わからない
   

   View Slide

10. 頼れる仲間はベトナムへ 10
    

    View Slide

11. 頼れる仲間はベトナムへ 11
    一緒にプロジェクトをする方が
    業務の都合で一か月海外出張へ
    

    View Slide

12. どうしたか 12
    ソースコードを見て
    仕様を把握して
    慎重に作る
    要するに頑張るしかなかった
    

    View Slide

13. 何があったらよかったか 13
    ビジネスロジックの
    テスト
    

    View Slide

14. テストがあったら 14
    テストがある in と out がわかる
    =
    これはもはや仕様書では？
    テストができる モックを差し込める
    =
    気軽に動かせて最高では？
    

    View Slide

15. テスト再考 15
    テストを再考した結果
    

    View Slide

16. テスト再考 16
    テスト最高！
    テストを再考した結果
    

    View Slide

17. 夢 17
    テストしやすい設計にしたい
    

    View Slide

18. クリーンアーキテクチャ 18
    テストしやすい設計といえば
    クリーンアーキテクチャ
    

    View Slide

19. クリーンアーキテクチャ 19
    最近の流行り？
    書籍 ホームページ
    

    View Slide

20. クリーンアーキテクチャ
    • 円はレイヤーを表す
    • Enterprise Business Rules
    • ビジネスロジックのレイヤー
    • Application Business Rules
    • ビジネスロジックの API が所属するレイヤー
    • Interface Adapters
    • 入力 / 出力 やデータ永続化関係
    • モデルを DB などに保存する処理はここ
    • Frameworks & Drivers
    • Web フレームワーク等々
    • 矢印は依存の方向
    • 変化しづらいビジネスロジックを中心に
    • 依存を一方向に限定して変化に対応
    • 外側のレイヤーが変更されても内部のレイヤーは
    変更不要
    20
    

    View Slide

21. クリーンアーキテクチャ 21
    • 円はレイヤーを表す
    • Enterprise Business Rules
    • ビジネスロジックのレイヤー
    • Application Business Rules
    • ビジネスロジックの API が所属するレイヤー
    • Interface Adapters
    • 入力 / 出力 やデータ永続化関係
    • モデルを DB などに保存する処理はここ
    • Frameworks & Drivers
    • Web フレームワーク
    • 矢印は依存の方向
    • 変化しづらいビジネスロジックを中心に
    • 依存を一方向に限定して変化に対応
    • 外側のレイヤーが変更されても内部のレイヤーは
    変更不要
    とにかくやってみよう
    

    View Slide

22. クリーンアーキテクチャ | 登場人物
    • UseCase
    • ビジネスロジックの API
    • interface や抽象クラス
    • Repository
    • GateWays
    • データ永続化に関するオブジェクト
    • リポジトリーパターン
    • Interactor
    • UseCase の実装クラス
    • ビジネスロジック
    • モック
    • Controller
    • 入力を解釈して UseCase に伝えるもの
    • MVC の Controller や単体テストクラスとか
    22
    もうちょっと詳しく -> https://nrslib.com/clean-architecture/
    動くサンプル欲しい -> https://github.com/nrslib/CleanArchitectureSample ※ Presenter は一旦置いておきます
    

    View Slide

23. クリーンアーキテクチャ | UseCase 23
    アプリケーションができる処理を interface で表現
    interface がない言語は完全抽象クラス
    Request と Response はただの DTO
    

    View Slide

24. クリーンアーキテクチャ | Repository 24
    リポジトリのインターフェースを定義
    いわゆるモデルの永続化や復元が責務
    データ永続化を行う実装クラス
    （サンプルは SQLを利用）は
    このリポジトリのインターフェースを実装する
    

    View Slide

25. クリーンアーキテクチャ | Interactor 25
    ビジネスロジックの実装
    処理の中身は
    トランザクションスクリプトでも
    ドメイン駆動設計でも
    なんでもいいです
    唯一気を付けるのは
    UI やインフラストラクチャの知識を書かないこと
    

    View Slide

26. クリーンアーキテクチャ | Controller 26
    Controller はユーザからの
    入力をユースケース用に変換
    UseCase を呼び出すだけ
    

    View Slide

27. クリーンアーキテクチャ | 処理の流れ 27
    

    View Slide

28. クリーンアーキテクチャ | 処理の流れ 28
    

    View Slide

29. クリーンアーキテクチャ | 処理の流れ 29
    

    View Slide

30. クリーンアーキテクチャ | 処理の流れ 30
    

    View Slide

31. クリーンアーキテクチャ | フロントエンドのテスト 31
    • バックエンドが未実装だけど先行してフロントエンドを作りたい
    • フロントで動作のテストをしたいけどデータを用意しづらい
    スタブの Interactor を用意すれば OK
    

    View Slide

32. クリーンアーキテクチャ | バックエンドのテスト 32
    • データベースがどれになるか決まらない
    • テスト用 DB に整合性のあるデータを用意するのが難しい
    スタブのリポジトリを用意すれば OK
    

    View Slide

33. クリーンアーキテクチャ | UseCase たくさん問題 33
    ユースケースごとにクラスを分けると
    MVC の場合はコントローラのフィールドが大変なことに
    

    View Slide

34. クリーンアーキテクチャ | Bus パターン 34
    特定の Response を取得することを期待して Request を作る
    Request を渡すと
    それに対応した
    Response を返してくれる
    Response さえもらえれば処理内容はなんでもいい
    

    View Slide

35. クリーンアーキテクチャ | Bus パターン 35
    cf.実装はこんな感じ
    

    View Slide

36. クリーンアーキテクチャ | Dependency Injection 36
    プロダクション環境とテスト環境で実行する
    Interactor を切り替えたい
    Bus
    Request Response
    Production
    Interactor
    Mock
    Interactor
    

    View Slide

37. クリーンアーキテクチャ | Dependency Injection 37
    DI Container で設定
    Test 環境 Product 環境
    プログラムに変更を加えることなく
    リポジトリや Interactor を切り替え
    

    View Slide

38. クリーンアーキテクチャ | Presenter 38
    これは何？
    

    View Slide

39. クリーンアーキテクチャ | Presenter 39
    Bus
    Request Response
    Production
    Interactor
    Mock
    Interactor
    例えば「処理の途中経過を表示したい」とき
    

    View Slide

40. クリーンアーキテクチャ | Presenter 40
    

    View Slide

41. クリーンアーキテクチャ | Presenter 41
    Interactor
    で使ってみる
    

    View Slide

42. クリーンアーキテクチャ | Presenter 42
    テスト用 プロダクト用
    

    View Slide

43. クリーンアーキテクチャ | Flow of control 43
    Flow of control
    

    View Slide

44. 夢のような世界
    • テストしやすい
    • モックの Interactor を使って好きなデータをフロントに送れる
    • バックエンドもデータ永続化処理や API も差し替え可能
    • 待たない
    • モックを差し込めるのでバックエンドを待つことなくフロントを作れる
    • 迷わない
    • ロジックを書く場所は必ず Interactor
    • 全ての処理はクラスになっているのでクラスからメソッドを探さなくていい
    • 移植可能
    • プレゼンテーション層（MVC フレームワーク等）にビジネスロジックが記述
    されないので dll 化してマルチプラットフォーム可能
    44
    

    View Slide

45. 現実 45
    • UseCase を定義
    • Request を定義
    • Response を定義
    • Interactor を定義
    • MockInteractor を定義
    • Test 用の Dependency Injection 設定
    • Production 用の Dependency Injection
    

    View Slide

46. 現実 46
    • UseCase を定義
    • Request を定義
    • Response を定義
    • Interactor を定義
    • MockInteractor を定義
    • Test 用の Dependency Injection 設定
    • Production 用の Dependency Injection
    面倒
    

    View Slide

47. 現実 47
    決まり切ったクラスの作成
    人間がやることではない
    決まり切った手順
    

    View Slide

48. 現実 48
    人間がやるべきでないことは
    プログラム＝ツールに任せよう
    

    View Slide

49. ツール | 概要 49
    DI 設定 Script / DI 設定ファイル
    UseCase 名を
    入力
    Request
    Response
    Product
    Interactor
    UseCase
    Test
    Interactor
    クラス生成
    ツールを作ります
    機能はクラスの生成と DI 登録
    

    View Slide

50. ツール | クラス生成 50
    UseCase と Request と Response は簡単
    

    View Slide

51. ツール | クラス生成 51
    Product 用の Interactor
    メソッドはとりあえず未実装
    

    View Slide

52. ツール | クラス生成 52
    Test 用の Interactor は
    とりあえず json 形式で書いたファイルから
    データを読み取るように
    デバッグ用ファイルのイメージ
    １回目の
    データ
    ２回目の
    データ
    

    View Slide

53. ツール | DI 登録 53
    DI の設定を自動で登録する
    Test 環境 Product 環境
    

    View Slide

54. ツール | デモ 54
    https://nrslib.com/clarc-csharp/
    ClArc
    

    View Slide

55. まとめ 55
    待ち時間の削減
    量産型コードの半自動化
    テスタビリティの確保
    

    View Slide

56. まとめ 56
    待ち時間の削減
    量産型コードの半自動化
    テスタビリティの確保
    アーキテクチャの防衛
    

    View Slide

57. 設計の理由 57
    アーキテクチャ（設計）を
    採用する理由は？
    そもそも
    ソフトウェアのアーキテクチャは
    何のために存在するのか？
    

    View Slide

58. ソフトウェアアーキテクチャの存在理由 58
    ソフトウェアアーキテクチャは
    システムのライフサイクルを
    サポートするために存在している
    開発 運用 保守
    

    View Slide

59. アーキテクチャを破壊する要素 59
    面倒と感じたらやらない
    設計に従ってもらうには
    それなりの理由が必要
    

    View Slide

60. アーキテクチャの防衛 60
    ツールによって面倒さを排除する
    従ったほうがより早く開発できる
    （よいユーザ体験）
    結果としてアーキテクチャが守られる
    

    View Slide

61. タイトル回収 61
    ツールで防衛
    クリーンアーキテクチャ
    

    View Slide