関心事と責務のお話
@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
【関心があるもの】
ビジネスロジック
【関心がないもの】
永続化の手段・手法
ここまでのまとめ
●大規模アプリケーションを作る場合でも、
責務が小さくなるように区切った単位で扱うことで
より柔軟に構築できる手法が確立
●どこまでプロダクトをスケールさせても
2つ先に存在するモノに対して関心をもたない
つくりになる
●もう一度みてみましょう
よくわかるまいくろさーびすのえ
認証サービス
決済
サービス
顧客管理
サービス
ポイント管理
サービス
検索
サービス
アプリ層
よくわかるどめいんくどうせっけいのえ
ドメイン層
UI層
インフラ層
EntityManager
よくわかるしんふぉにーのえ
Repository
Service
Entity
Controller
☕
前半のまとめ
●アプリケーションを作る場合、
責務が小さくなるように区切った単位で扱うことで
より柔軟に構築できる手法が確立
●どこまでプロダクトをスケールさせても
2つ先に存在するモノに対して関心をもたない
つくりになる
●もう一度みてみましょう
関心事と
責務のお話
関心事って?
関心の分離(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だけを先にガツッとつくってみる
○ “その”設計がどこまで通用するかを確認する目的
●関心を持つのは相手のみ!
○ 2つ先の相手(相手の相手)に関心をもたない
●クラスの責務は広くない?
手順
手順
注意事項
考え事
考え事
設計・コーディング手順と考え事
●設計思想を言語化する
○ 後からメンテするときに響いてきます!
●思想にあうようにIFだけを先にガツッとつくってみる
○ “その”設計がどこまで通用するかを確認する目的
●関心を持つのは相手のみ!
○ 2つ先の相手(相手の相手)に関心をもたない
●クラスの責務は広くない?
手順
手順
注意事項
考え事
考え事
設計・コーディング手順と考え事
●設計思想を言語化する
○ 後からメンテするときに響いてきます!
●思想にあうようにIFだけを先にガツッとつくってみる
○ “その”設計がどこまで通用するかを確認する目的
●関心を持つのは相手のみ!
○ 2つ先の相手(相手の相手)に関心をもたない
●クラスの責務は広くない?
「抽象に依存する」
って言ったりします
どこが悪いでしょう?
どこが悪いでしょう?
どこが悪いでしょう?
今までのお話はすべて数ある思想の中の一例
取り組むにあたって...
●自由度の高いフレームワークの恩恵を享受しよう!
○ たとえばLaravelとか
●何をするにもインターフェースから
○ 手戻り激しくてやる気がね...
●節度をもって、楽しく取り組みましょう!
○ 厳密にやりすぎるとかえって使いづらくなったり,,,
どう取り組むか
書籍・アンテナの紹介
● http://ja.phptherightway.com/
● https://プログラマが知るべき97のこと.com/
● 書籍:達人プログラマー
もう一度まとめ
「関心の分離」をして
責務の小さな
クラス設計をしよう!
隣のビル(A館)の27Fで一緒に働きましょう!

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