How to start software design

How to start software design

A967476c5855d593710a9a580f6b2aed?s=128

Yuichi Maekawa

November 04, 2018
Tweet

Transcript

  1. ソフトウェア設計の始め方 kaelaela(Yuichi Maekawa) @未来大ITアーキテクチャ特論 2018/10/31

  2. 今日の話 「大学の講義でもよく聞くソフトウェアの設計。MVCやClean ArchitectureやDDD、最近はFluxやReduxなんかもよく聞く。実 際に自分がソフトウェア開発をするときに、何を選べばいいの か?今動いているソフトウェアの設計の何が悪いのか?この講義 では多種多様なソフトウェア設計のそれぞれについて一通り目を 通し、それらをどのようなときに使うべきか自分で判断するための 方法を学べます。」

  3. 今日の話 「大学の講義でもよく聞くソフトウェアの設計。MVCやClean ArchitectureやDDD、最近はFluxやReduxなんかもよく聞く。実 際に自分がソフトウェア開発をするときに、何を選べばいいの か?今動いているソフトウェアの設計の何が悪いのか?この講義 では多種多様なソフトウェア設計のそれぞれについて一通り目を 通し、それらをどのようなときに使うべきか自分で判断するための 方法を学べます。」 4行で言うと

  4. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する Only these!
  5. 設計とは ソフトウェア開発を行う上で、多くのプログラマがこれまでの経験 や知識を活かして考えだしたアーキテクチャパターンのこと。パ ターンとは型、様式のことであり、このときはこのようにするといっ た決まりごとを言う。

  6. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  7. 設計が多すぎる... • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture • ドメイン駆動設計(DDD) ...
  8. 設計ではないもの • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture • ドメイン駆動設計(DDD) ...
  9. いきなりDDD 設計を理解しきれていない今だからこそ覚えておき たい。ドメイン駆動設計(DDD)は特定の設計手法で はない。 ドメインモデルという概念を理解し、それを中心に考 えて(=ドメイン駆動)開発を行うための方法論である。

  10. ドメインモデル

  11. ドメイン|モデル

  12. モデルとは何か? 多くの場合は人が理解可能なモノ・概念を 指し、現実世界よりもプログラム上で扱いや すく抽象化された単一の存在。 ex. りんご、車、買い物、ユーザー

  13. モデルとは何か? 簡単にいうとプログラム上で扱う、 UI(User Interface)以外のほぼすべて。

  14. ドメインモデルとは ドメイン=我々がプログラムにしたいと思う対象とその領域。ドメイ ンモデルとはその領域中に存在するモデルを指す。料理を手助け するアプリを作成する場合、調理器具や食材、調理方法、ユー ザー自身などを指す。 ドメインモデルの構築が重要であり、ドメインエキスパート(ここで は料理人、料理研究家、料理するユーザー)と共に決定していく。

  15. 詳しくは…

  16. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  17. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  18. エンタープライズアプリケーション アーキテクチャパターン

  19. ドメインの複雑性に対応した設計

  20. ドメインの複雑性に対応した設計

  21. ドメインの複雑性に対応した設計

  22. ドメインの複雑性に対応した設計

  23. 単純なアプリ

  24. 端末だけでは完結しないアプリ

  25. 難しいドメインのアプリ

  26. 難しいドメイン+大規模な組織で開発するアプリ

  27. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  28. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  29. 開発するのはどんなものだろう?

  30. 単純なアプリ • 結果表示ロジック • 計算ロジック • ボタン入力の処理

  31. 端末だけでは完結しないアプリ • 表示ロジック • ボタン入力の処理 • サーバーとの通信処理 • シェア機能

  32. 難しいドメインのアプリ(例) • 撮影ロジック • 補正ロジック • 加工ロジック • ローカル保存 •

    キャッシュ • サーバーへアップロード など
  33. 難しいドメイン+大規模な組織で開発するアプリ • 動画再生ロジック • ユーザー状態管理 • ダウンロード機能 • 課金機能 など

  34. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  35. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  36. 開発組織とソフトウェア設計 コンウェイの法則に従い、アプリケーションは組織の構成に似る。 Abemaでいうと、ビデオ機能チームが存在するとビデオ機能レイ ヤやモジュールみたいなものがアプリケーションにも存在する。 Android チーム ビデオ チーム テレビチー ム

    Android アプリ ビデオ 機能 テレビ 機能 開発組織 設計
  37. チームにおける良い設計 • 経験の違うメンバーがすぐ開発できる・引き継げる • 比較的に単純である • 冗長性が少ない • 拡張するときに設計をはみ出さない •

    後から大改修する必要がない
  38. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  39. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する
  40. 適切な設計とは?

  41. アプリケーション開発の問題は複雑 スパゲティコード ドキュメントがない 機能追加がしにくい ビルドが重い 仕様変更が多い UI変更が頻繁に起こる イケてるアプリと言いたい 仕様が難解 人が足りない

    開発メンバーの実力差が大きい 技術的負債や歴史がそのままになっている 工数が短い
  42. アプリケーション開発の問題は複雑 スパゲティコード ドキュメントがない 機能追加がしにくい ビルドが重い 仕様変更が多い UI変更が頻繁に起こる イケてるアプリと言いたい 仕様が難解 人が足りない

    開発メンバーの実力差が大きい 技術的負債や歴史がそのままになっている 工数が短い 設計で カバー!!!
  43. 現実は厳しい スパゲティコード ドキュメントがない 機能追加がしにくい ビルドが重い 仕様変更が多い UI変更が頻繁に起こる イケてるアプリと言いたい 仕様が難解 人が足りない

    開発メンバーの実力差が大きい 技術的負債や歴史がそのままになっている 工数が短い 設計で カバー!!!
  44. スパゲティコード ドキュメントがない 機能追加がしにくい ビルドが重い 仕様変更が多い UI変更が頻繁に起こる イケてるアプリと言いたい 仕様が難解 人が足りない 開発メンバーの実力差が大きい

    技術的負債や歴史がそのままになっている 工数が短い スコープを決め、適した解決策を選ぼう ~~アーキテクチャで解決
  45. 適切な設計は解決したい問題が明確

  46. 目的にあう設計を選ぶ=設計を知ってる

  47. すべて詳しくは無理なので… いろんな設計を簡単に説明

  48. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  49. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  50. MV whateverアーキテクチャ • Model : アーキテクチャごとに若干異なる • View : ユーザーとのinterface、タッチイベントの発火元

    • whateverはこの2つを繋ぐ「何か」 • MVC, MVP, MVVMなどが一般的 • レイヤ間の呼び出しはobserverパターンが基本
  51. MVC Model, View, Controllerの三つの概念で設計する手法。 1979年にTrygve Reenskaugが発表

  52. MVC • Model: 人がイメージした何か • View: Modelの一部を視覚的に表したもの • Controller: ユーザーの行動でシステムを変更する機構

  53. MVCの使い所 • 大事なのはモデルとそれ以外の部分を分離できること • とても単純&始めやすい • 1人で開発してるもの

  54. MVP Taligent(Apple + IBMの合同会社)で使われ始めたMVCの派 生アーキテクチャ。Mike Potelの論文で認知された • Model, Viewは同じだが、新しくPresenterを導入 •

    データの流れがMVCより明確 • 複雑なUIの表示ロジックをPresenterが処理する Model Presenter View インターフェイス
  55. MVPの使い所 • MVCより複雑な表示ロジックを持つアプリ • アプリ内のでデータの流れをより明確にしたい • 一人で開発してるもの

  56. Model, View, Viewmodelに分けて作る方法。Microsoftの Ken CooperとTed Petersが開発、2004年にJohn Gossmanがブログで提唱。Presentation Modelがベース。 MVVM Model

    ViewModel View Data Binding
  57. MVVM • View -> ViewModel -> Modelの単一方向に依存 • Data Binding機構を持つのが特徴

    • データ変更すると表示が即時反映 Model ViewModel View Data Binding
  58. MVVMの使い所 • 状態管理が複雑なアプリ • 画面の状態を超えてデータや状態を保存するとき • 複数人で開発しているもの • ライフサイクルが影響するアプリ

  59. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  60. CQRS Command Query Responsibility Segregationの略。 Bertrand MeyerやGreg Youngらが提唱したパラダイム。 CommandとQueryを分離する設計。 Application

    Data Command Query
  61. CQRS • Command ユーザーの行動から、データやシステムの状態を変更するこ とにだけ着目した処理。同じ入力に対して、冪等が保証されて いる。Write Onlyで値を返さない。 Application Data Command

    Query
  62. CQRS • Query ユーザーの行動からデータやシステムの状態を読み込むだけ に着目した処理。Read Onlyで処理に副作用がない。 Application Data Command Query

  63. CQRSの使い所 • DataBindingができているシステムでは導入が楽かも • 書き込みと読み込み処理が複雑なシステム • DDDベースのシステムでのリファクタ • Fluxも相性が良さそう

  64. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  65. Flux • 2014年にFacebookが提唱 • JavascriptでMV~パターンの問題を解決するため • もっとも重要なコンセプトはデータの流れが一方向

  66. Flux • Action 行動や操作の起点。Dispatcherへデータやイベントを渡す のが役目。

  67. Flux • Dispatcher イベントをStoreに通知するのが役目。

  68. Flux • Store Viewの状態管理、データの加工、Viewへの通知を行う。

  69. Fluxの使い所 • Reactiveなデータ反映を行うシステム • シンプルなデータフローにしたいとき • 大規模で拡張されやすいシステム • 大人数で開発する可能性のあるシステム

  70. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  71. Redux Fluxからの派生アーキテクチャ(Store実装の一つなどとも言わ れる)。データフローが一方向であるのは同じ。大きな違いは Storeが一つであること、DispatcherがなくActionを直接 ViewからStoreへと送るなどがあげられる。

  72. Redux Redux三原則がある。 • Single source of truth • State in

    read-only • Changes are made with pure functions
  73. Redux • Single source of truth Storeが全ての状態を管理し、アプリ全体で一つだけ存在する。 シングルトンのオブジェクトツリー。

  74. • State in read-only Stateは読み取り専用であり、変更するのはActionを通じて Store内でReducerが行う。View側から直接変更されることが ない。 Redux

  75. Redux • Changes are made with pure functions Stateの変更はReducerが行うが、ReducerはActionとある Stateを受け取り、別なStateを返すだけで副作用のない純粋な

    関数である。
  76. Reduxの使い所 • Fluxでの状態管理がうまくいってないとき • Rxがうまく使えてないシステム • システム全体に影響する状態変更が不明瞭なとき

  77. 設計 • MVC • MVP • MVVM • CQRS •

    Flux • Redux • Clean Architecture ...
  78. Clean Architecture Uncle Bobが2012年にブログで提唱。DDDをベースとしてい る。レイヤーを多段にわけ、それぞれの関心を分離するのが目 的。依存性の方向は内側に向かってのみ可能。(内側の層は外側 の層について知らない)

  79. • Enterprise Business Rules 事業のビジネスロジック。データそのものが持つルール。 Entityはデータを保持するだけのオブジェクト。 Clean Architecture

  80. Clean Architecture • Application Business Rules アプリケーション固有のビジネスロジック。個々のアプリケー ションごとに変わり得るルール。

  81. Clean Architecture • Interface Adapters アプリケーションの外からドメインに関わる部分のデータを変 換する。UIに限らずDBなどに対しても働く。

  82. Clean Architecture • Frameworks & Drivers アプリの外側の世界。UIやデータストア、ライブラリやフレーム ワークなど。

  83. Clean Architectureの使い所 • システム全体の結合度を下げたいとき • 既存アーキテクチャと併用してクリーンにしたい • 現状テストが書きにくいシステム • 大規模で拡張されやすいシステム

    • 大人数で開発する可能性のあるシステム
  84. よくある設計の認識 • レイヤーを分ければいい • 導入すればFatな部分が無くなる • 導入すればテストが書ける • 導入すると兎に角幸せになれる •

    最新のアーキテクチャは完璧
  85. 僕が昔した設計(?)の失敗 • 複数のGODクラス駆逐に疲弊 >そうだ設計で解決しよう • ルールを決めずに各々できるところから置き換え >MVC+MVP+MVVMが悪魔合体したキメラプロジェクト • 泣きながらMVCとMVVMを駆逐 >残されたFatViewとFatPresenter

    >なんの成果も得られませんでした<
  86. 僕が好きな設計 • 着想がシンプル • ルールが明確 • データの流れがすぐにわかる • 人が起こすエラーに強い •

    間違えたときにすぐ気が付ける(できれば自動で) • 書き方を強制できる
  87. 学生にも設計を考えて欲しい

  88. ハッカソンして学生の設計を見よう

  89. None
  90. Git Push Hackathonについて • ネイティブ限定のオンラインハッカソン ◦ https://github.com/CyberAgent/git-push-hackathon • テーマ:githubのフィードを読み込む簡単なアプリ •

    オンラインで完結したので地方学生も参加できた • 評価のポイントは ◦ 設計 ◦ 最新技術、言語仕様を正しく用いた実装 ◦ UI/UXへのこだわり(+α要素として評価)
  91. GPHを通じてわかった学生が考える設計 • 「MV~~を導入」したら設計 • 導入すればシステムがよくなる • webで「〜アプリ 設計」と検索した通りに実装

  92. 学生に知ってほしい設計 • Modelの定義が適切か • 「導入したら」ではなく「ある課題を解決する」が設計 • 設計がないと、読めるが難解 • 設計されていると実装がイメージについてくる (これを調べるにはここ。などわかる)

  93. ソフトウェア設計の始め方 • プログラムの対象領域に詳しくなる (or 詳しい人を呼ぶ) • モデルが持つロジックの量と複雑さを決める • 開発組織や作るものの成長速度を考える •

    適切な設計を選択し導入する