ツールで防衛 クリーンアーキテクチャ / 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
2. 自己紹介 • 成瀬 允宣 - Masanobu Naruse • GMOインターネット（システム本部 UXデザイン開発部） • プログラマ • C# , Typescript, Scala • DDD とかアーキテクチャの話が好きです • @nrslib • https://nrslib.com/ 2
3. セッションの目的 3 クリーンアーキテクチャ を 実践できるようになる
4. もくじ • 直近の苦労話 • 何が問題だったのか • 思い描いた夢 • クリーンアーキテクチャ • 立ちはだかる現実 • アーキテクチャのための冗長化に対する解決方法 • 最後に 4
5. 直近の辛かったプロジェクト 5 前任者無し 仕様書無し 頼れる仲間はベトナムへ
6. 前任者無し 6 前任者が退職
7. 前任者無し 7 前任者が退職 将来利用される予定のコード 現在利用されているコード 混在
8. 仕様書無し 8 どういう入力をすると どういう出力が返ってくるか わからない
9. 仕様書無し 9 どういう入力をすると どういう出力が返ってくるか わからない というかそもそも どういう入力をすればいいのか わからない
10. 頼れる仲間はベトナムへ 10
11. 頼れる仲間はベトナムへ 11 一緒にプロジェクトをする方が 業務の都合で一か月海外出張へ
12. どうしたか 12 ソースコードを見て 仕様を把握して 慎重に作る 要するに頑張るしかなかった
13. 何があったらよかったか 13 ビジネスロジックの テスト
14. テストがあったら 14 テストがある in と out がわかる = これはもはや仕様書では？ テストができる モックを差し込める = 気軽に動かせて最高では？
15. テスト再考 15 テストを再考した結果
16. テスト再考 16 テスト最高！ テストを再考した結果
17. 夢 17 テストしやすい設計にしたい
18. クリーンアーキテクチャ 18 テストしやすい設計といえば クリーンアーキテクチャ
19. クリーンアーキテクチャ 19 最近の流行り？ 書籍 ホームページ
20. クリーンアーキテクチャ • 円はレイヤーを表す • Enterprise Business Rules • ビジネスロジックのレイヤー • Application Business Rules • ビジネスロジックの API が所属するレイヤー • Interface Adapters • 入力 / 出力 やデータ永続化関係 • モデルを DB などに保存する処理はここ • Frameworks & Drivers • Web フレームワーク等々 • 矢印は依存の方向 • 変化しづらいビジネスロジックを中心に • 依存を一方向に限定して変化に対応 • 外側のレイヤーが変更されても内部のレイヤーは 変更不要 20
21. クリーンアーキテクチャ 21 • 円はレイヤーを表す • Enterprise Business Rules • ビジネスロジックのレイヤー • Application Business Rules • ビジネスロジックの API が所属するレイヤー • Interface Adapters • 入力 / 出力 やデータ永続化関係 • モデルを DB などに保存する処理はここ • Frameworks & Drivers • Web フレームワーク • 矢印は依存の方向 • 変化しづらいビジネスロジックを中心に • 依存を一方向に限定して変化に対応 • 外側のレイヤーが変更されても内部のレイヤーは 変更不要 とにかくやってみよう
22. クリーンアーキテクチャ | 登場人物 • UseCase • ビジネスロジックの API • interface や抽象クラス • Repository • GateWays • データ永続化に関するオブジェクト • リポジトリーパターン • Interactor • UseCase の実装クラス • ビジネスロジック • モック • Controller • 入力を解釈して UseCase に伝えるもの • MVC の Controller や単体テストクラスとか 22 もうちょっと詳しく -> https://nrslib.com/clean-architecture/ 動くサンプル欲しい -> https://github.com/nrslib/CleanArchitectureSample ※ Presenter は一旦置いておきます
23. クリーンアーキテクチャ | UseCase 23 アプリケーションができる処理を interface で表現 interface がない言語は完全抽象クラス Request と Response はただの DTO
24. クリーンアーキテクチャ | Repository 24 リポジトリのインターフェースを定義 いわゆるモデルの永続化や復元が責務 データ永続化を行う実装クラス （サンプルは SQLを利用）は このリポジトリのインターフェースを実装する
25. クリーンアーキテクチャ | Interactor 25 ビジネスロジックの実装 処理の中身は トランザクションスクリプトでも ドメイン駆動設計でも なんでもいいです 唯一気を付けるのは UI やインフラストラクチャの知識を書かないこと
26. クリーンアーキテクチャ | Controller 26 Controller はユーザからの 入力をユースケース用に変換 UseCase を呼び出すだけ
27. クリーンアーキテクチャ | 処理の流れ 27
28. クリーンアーキテクチャ | 処理の流れ 28
29. クリーンアーキテクチャ | 処理の流れ 29
30. クリーンアーキテクチャ | 処理の流れ 30
31. クリーンアーキテクチャ | フロントエンドのテスト 31 • バックエンドが未実装だけど先行してフロントエンドを作りたい • フロントで動作のテストをしたいけどデータを用意しづらい スタブの Interactor を用意すれば OK
32. クリーンアーキテクチャ | バックエンドのテスト 32 • データベースがどれになるか決まらない • テスト用 DB に整合性のあるデータを用意するのが難しい スタブのリポジトリを用意すれば OK
33. クリーンアーキテクチャ | UseCase たくさん問題 33 ユースケースごとにクラスを分けると MVC の場合はコントローラのフィールドが大変なことに
34. クリーンアーキテクチャ | Bus パターン 34 特定の Response を取得することを期待して Request を作る Request を渡すと それに対応した Response を返してくれる Response さえもらえれば処理内容はなんでもいい
35. クリーンアーキテクチャ | Bus パターン 35 cf.実装はこんな感じ
36. クリーンアーキテクチャ | Dependency Injection 36 プロダクション環境とテスト環境で実行する Interactor を切り替えたい Bus Request Response Production Interactor Mock Interactor
37. クリーンアーキテクチャ | Dependency Injection 37 DI Container で設定 Test 環境 Product 環境 プログラムに変更を加えることなく リポジトリや Interactor を切り替え
38. クリーンアーキテクチャ | Presenter 38 これは何？
39. クリーンアーキテクチャ | Presenter 39 Bus Request Response Production Interactor Mock Interactor 例えば「処理の途中経過を表示したい」とき
40. クリーンアーキテクチャ | Presenter 40
41. クリーンアーキテクチャ | Presenter 41 Interactor で使ってみる
42. クリーンアーキテクチャ | Presenter 42 テスト用 プロダクト用
43. クリーンアーキテクチャ | Flow of control 43 Flow of control
44. 夢のような世界 • テストしやすい • モックの Interactor を使って好きなデータをフロントに送れる • バックエンドもデータ永続化処理や API も差し替え可能 • 待たない • モックを差し込めるのでバックエンドを待つことなくフロントを作れる • 迷わない • ロジックを書く場所は必ず Interactor • 全ての処理はクラスになっているのでクラスからメソッドを探さなくていい • 移植可能 • プレゼンテーション層（MVC フレームワーク等）にビジネスロジックが記述 されないので dll 化してマルチプラットフォーム可能 44
45. 現実 45 • UseCase を定義 • Request を定義 • Response を定義 • Interactor を定義 • MockInteractor を定義 • Test 用の Dependency Injection 設定 • Production 用の Dependency Injection
46. 現実 46 • UseCase を定義 • Request を定義 • Response を定義 • Interactor を定義 • MockInteractor を定義 • Test 用の Dependency Injection 設定 • Production 用の Dependency Injection 面倒
47. 現実 47 決まり切ったクラスの作成 人間がやることではない 決まり切った手順
48. 現実 48 人間がやるべきでないことは プログラム＝ツールに任せよう
49. ツール | 概要 49 DI 設定 Script / DI 設定ファイル UseCase 名を 入力 Request Response Product Interactor UseCase Test Interactor クラス生成 ツールを作ります 機能はクラスの生成と DI 登録
50. ツール | クラス生成 50 UseCase と Request と Response は簡単
51. ツール | クラス生成 51 Product 用の Interactor メソッドはとりあえず未実装
52. ツール | クラス生成 52 Test 用の Interactor は とりあえず json 形式で書いたファイルから データを読み取るように デバッグ用ファイルのイメージ １回目の データ ２回目の データ
53. ツール | DI 登録 53 DI の設定を自動で登録する Test 環境 Product 環境
54. ツール | デモ 54 https://nrslib.com/clarc-csharp/ ClArc
55. まとめ 55 待ち時間の削減 量産型コードの半自動化 テスタビリティの確保
56. まとめ 56 待ち時間の削減 量産型コードの半自動化 テスタビリティの確保 アーキテクチャの防衛
57. 設計の理由 57 アーキテクチャ（設計）を 採用する理由は？ そもそも ソフトウェアのアーキテクチャは 何のために存在するのか？
58. ソフトウェアアーキテクチャの存在理由 58 ソフトウェアアーキテクチャは システムのライフサイクルを サポートするために存在している 開発 運用 保守
59. アーキテクチャを破壊する要素 59 面倒と感じたらやらない 設計に従ってもらうには それなりの理由が必要
60. アーキテクチャの防衛 60 ツールによって面倒さを排除する 従ったほうがより早く開発できる （よいユーザ体験） 結果としてアーキテクチャが守られる
61. タイトル回収 61 ツールで防衛 クリーンアーキテクチャ