Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

「関心事」と「責務」 の お話

2,026 views

Published on

phpカンファレンス関西2017

Published in: Technology

「関心事」と「責務」 の お話

  1. 1. 関心事と責務のお話 @PHPカンファレンス関西2017 Shinichi Takahashi
  2. 2. おねがい ●発表中、リアクションがあるとうれしいです ○ 😲なるほど〜 ○ 😫こいつ何いってっかマジわかんねえ ○ 😏マサカリ投げますね とかとか ●質問を考えながら聞いて欲しいです ○ 5分前に終了して質疑応答時間をとります ○ 質問がなくて早く終わるとさびしいです😥 ●いわゆる「すごい人」ではありません
  3. 3. もくじ ●あれこれのお話 (ちょっとお水のんで) ●後半:関心事と責務のお話
  4. 4. あれこれのお話
  5. 5. ●James Lewis氏によって2014年頃に提案された言葉 ●氏の提唱する特徴 ○ サービスによるコンポーネント化 ○ ビジネスケイパビリティに基づく組織化 ○ プロジェクトではなくプロダクト ○ スマートエンドポイントとダムパイプ ○ 分散型ガバナンス ○ 分散データ管理 ○ インフラストラクチャ自動化 ○ 障害設計 ○ 進化的設計 マイクロサービス - Microservices https://martinfowler.com/articles/microservices.html
  6. 6. スマートエンドポイントとダムパイプ 異なるプロセス間でのコミュニケーション構造を ●スマートエンドポイント ○ RESTishなリソースAPI ●ダムパイプ ○ RabbitMQ や ZeroMQ などの軽量メッセージングダム (メッセージルータ)を通じて通信を行う を用いて構築する https://martinfowler.com/articles/microservices.html
  7. 7. 分散型ガバナンス モノリスは通常単一言語であり、使用するテクノロジの数を 制限する傾向があるけど、 マイクロサービスでは... ●サービスごとの言語・DBなどの選択が自由 ●サービスごとに適切な構成をとることを推奨 ○ わざわざNode.jsで簡単なレポートページつくったり😂 ○ トランザクショナルな処理に非同期なDBつかったり😂 ○ そんなことはしなくていいです!全部自由!🍺
  8. 8. よくわかるまいくろさーびすのえ 認証サービス 決済 サービス 顧客管理 サービス ポイント管理 サービス 検索 サービス 【関心があるもの】 APIの通信規約 (インターフェース) レイテンシ 【関心がないもの】 DBの種類 アプリケーション実装言語 採用されたフレームワーク
  9. 9. ●Eric Evans氏によって提唱された言葉 ●氏の提唱する特徴 ○ 複雑なドメインの設計は、モデルベースで行うべき ○ システムを実装するための特定の技術ではなく、 ドメインそのものとドメインのロジックに焦点を置くべき ●ドメインモデルの表現要素 ○ Entity ○ Value Object ○ Service ○ Repository ○ Factory ドメイン駆動設計 - DomainDrivenDesign https://martinfowler.com/articles/microservices.html
  10. 10. ドメインモデルとは?
  11. 11. アプリ層 よくわかるどめいんくどうせっけいのえ ドメイン層 UI層 インフラ層 【関心があるもの】 ビジネスロジック 【関心がないもの】 DBの種類
  12. 12. EntityManager よくわかるしんふぉにーのえ Repository Service Entity Controller 【関心があるもの】 ビジネスロジック 【関心がないもの】 永続化の手段・手法
  13. 13. ここまでのまとめ ●大規模アプリケーションを作る場合でも、 責務が小さくなるように区切った単位で扱うことで より柔軟に構築できる手法が確立 ●どこまでプロダクトをスケールさせても 2つ先に存在するモノに対して関心をもたない つくりになる ●もう一度みてみましょう
  14. 14. よくわかるまいくろさーびすのえ 認証サービス 決済 サービス 顧客管理 サービス ポイント管理 サービス 検索 サービス
  15. 15. アプリ層 よくわかるどめいんくどうせっけいのえ ドメイン層 UI層 インフラ層
  16. 16. EntityManager よくわかるしんふぉにーのえ Repository Service Entity Controller
  17. 17.
  18. 18. 前半のまとめ ●アプリケーションを作る場合、 責務が小さくなるように区切った単位で扱うことで より柔軟に構築できる手法が確立 ●どこまでプロダクトをスケールさせても 2つ先に存在するモノに対して関心をもたない つくりになる ●もう一度みてみましょう
  19. 19. 関心事と 責務のお話
  20. 20. 関心事って? 関心の分離(separation of concerns)とは、 ソフトウェア工学において、プログラムを機能面に おいて可能な限り重複がない、複数の機構に明確に 分割することをいう。 ここでいう「関心(関心事)」とは、プログラムの ある機能や振る舞い、目的のことである。 https://ja.wikipedia.org/wiki/%E9%96%A2%E5%BF%83%E3%81%AE%E5%88 %86%E9%9B%A2
  21. 21. 責務って? そのクラスがなすべきこと。 クラスを設計する場合にはそのクラスの責務をよく検討する 必要がある。 クラスの責務があいまいなままになっていると、 コーディングやデバッグがしにくくなり、 また機能追加も困難になることが多い。 http://www.hyuki.com/oo/#oo03
  22. 22. これらを意識しないと... ●密結合で ○ 依存の強い ○ 拡張性・メンテ性の低い ●スパゲッティになりやすい ●設計思想のない コードが生まれやすくなります。
  23. 23. 先にまとめ 「関心の分離」をして 責務の小さな クラス設計をしよう!
  24. 24. たとえばCakePHP 2の場合 Model ビジネスロジックを担当 [責務] ビジネスロジック データの取得 データの永続化 入力値の検証 View UIへの出力を担当 [責務] Model(データ)をHTMLや JSONなどで表現 Controller UIからの入力を担当 [責務] 入力を判断 Modelと紐付け 責務が大きく よくfat modelとか 言われてました
  25. 25. MVCを疑問視してみる Requestを検証 DataStore 入力を判断 (処理のふりわけ) 保存するデータの検証・保存 結果/データセットの取得 結果を判断 (処理のふりわけ) Responseデータの返却 Model Controller View Controller ビジネスロジック Model Model Controller / Model
  26. 26. fat modelの問題点 ●Modelの担当範囲が広い ○ == 関心事が多い ●Requestサイクル内でControllerを挟んだりしがち ○ 直感的ではない ○ エンジニアによって書き方がばらつく可能性を含む ●fatって言われると僕が傷つく ○ 3項目ならべないとバランスが悪くなるので...😂
  27. 27. ●直感的 ●変更につよい ●誰が書いても同じような実装になる ●テストに強い はいそうですね 理想論
  28. 28. 設計・コーディング手順と考え事 ●設計思想を言語化する ○ 後からメンテするときに響いてきます! ●思想にあうようにIFだけを先にガツッとつくってみる ○ “その”設計がどこまで通用するかを確認する目的 ●関心を持つのは相手のみ! ○ 2つ先の相手(相手の相手)に関心をもたない ●クラスの責務は広くない? 手順 手順 注意事項 考え事 考え事
  29. 29. 設計・コーディング手順と考え事 ●設計思想を言語化する ○ 後からメンテするときに響いてきます! ●思想にあうようにIFだけを先にガツッとつくってみる ○ “その”設計がどこまで通用するかを確認する目的 ●関心を持つのは相手のみ! ○ 2つ先の相手(相手の相手)に関心をもたない ●クラスの責務は広くない? 手順 手順 注意事項 考え事 考え事
  30. 30. 設計・コーディング手順と考え事 ●設計思想を言語化する ○ 後からメンテするときに響いてきます! ●思想にあうようにIFだけを先にガツッとつくってみる ○ “その”設計がどこまで通用するかを確認する目的 ●関心を持つのは相手のみ! ○ 2つ先の相手(相手の相手)に関心をもたない ●クラスの責務は広くない? 「抽象に依存する」 って言ったりします
  31. 31. どこが悪いでしょう?
  32. 32. どこが悪いでしょう?
  33. 33. どこが悪いでしょう?
  34. 34. 今までのお話はすべて数ある思想の中の一例 取り組むにあたって... ●自由度の高いフレームワークの恩恵を享受しよう! ○ たとえばLaravelとか ●何をするにもインターフェースから ○ 手戻り激しくてやる気がね... ●節度をもって、楽しく取り組みましょう! ○ 厳密にやりすぎるとかえって使いづらくなったり,,, どう取り組むか
  35. 35. 書籍・アンテナの紹介 ● http://ja.phptherightway.com/ ● https://プログラマが知るべき97のこと.com/ ● 書籍:達人プログラマー
  36. 36. もう一度まとめ 「関心の分離」をして 責務の小さな クラス設計をしよう!
  37. 37. 隣のビル(A館)の27Fで一緒に働きましょう!

×