Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

nrs
September 01, 2018

ツールで防衛 クリーンアーキテクチャ / 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

nrs

September 01, 2018
Tweet

More Decks by nrs

Other Decks in Programming

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 形式で書いたファイルから
    データを読み取るように
    デバッグ用ファイルのイメージ
    1回目の
    データ
    2回目の
    データ

    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