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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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