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