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

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

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

Check these out next

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

Recommended

More Related Content

More from Shinichi Takahashi(16)

Recently uploaded(20)