readonly classで作る堅牢なアプリケーション
Immutableである点が良い。
よくよく考えるとCarbonの仕様って意味わからない。
ORMとの相性が悪いのでImmutableなドメインクラスに変換して使うようにするといい。
スケーラブルサービスーー疎結合に成長するシステムに不可欠な要素
システム観点からのスケーリング
マシンのスケーリング
-> サービスが停止できるかどうかに依存する。
もし停止できないなら一時的なスケールアウトを踏んでスケールアップするしかない。
-> LBでスケールアウト後のマシンにリクエストを流す。その後小さい方を削除。
機能単位でのスケーリング
->特定の機能を他のインスタンスに切り分けられるかどうかに依存する。
1. 単純にインスタンスを分けてHTTP通信でやる場合。
SLAが下がる。
2. 1.の解決策としてメッセージ駆動なシステムに取り組む
機能ごとに分けたそれぞれのサービスをメッセージブローカーに依存させる。
メッセージブローカーには2種類ある
1. キュー
コンシューマーがキューのデータを取得するとキューからデータが消える。
2. ストリーム
コンシューマーがキューのデータを取得してもキューからデータが消えない。
いつ消えるか？
期間で管理する。
つまり複数のコンシューマーが同じデータを受け取れる。
3. メッセージブローカーの課題
順序保証
1. メッセージを貯める時の課題
メッセージが送信先トピックが分かれると順序保証されない
-> 各メッセージにIDを振ってtopicごとに割り振られるようにすればいい。
2. メッセージを受け取る時の課題
コンシューマーが複数いる際、メッセージが分裂して順序が保たれないかも。
-> 全てのコンシューマーにブロードキャストして自分の担当ではないIDのメッセージは破棄するようにすればいい。
4. メッセージブローカーの課題2
送信取り消し
-> OutBoxパターンで送信したいイベントをDBに記録し、そのデータを監視することでメッセージブローカーに通知すればいい
-> 実装にはCDCなどを使う。
2. インスタンスを跨ぐ処理はDBトランザクションが使えない
補償トランザクション（sagaパターンともいう）という考え方でロールバックする
JOINなどでインスタンスを跨ぎたい場合は、CDCなどでデータを集めて新しいView用DBを作成できる。
5. まとめ
補償トランザクション の実装さえできれば機能単位でのスケーリングが可能となる。
メッセージ駆動のメリット
どんなメッセージを受け取って何を返すかという形に整理できる。
= 関数化できる。引数はメッセージを表すようにすればいい。
更なるメリット
未来予測が難しい機能もイベントソーシングと組み合わせることで実現できる。（機能のスケーリング）
Symfony+Doctrine ORMで始める安全なモジュラモノリス - Speaker Deck
1. サービス層でのモジュール間の依存関係はinterfaceとDIによって解決する
2. ORMによる依存関係の解決にはDoctrineのオブジェクトのInterafceを指定する機能で対応する。
Doctrineは意識せずともLaravelが裏側で使っていたような気がしたので気になってこのTrackを聞いた。
Doctrineの方がEloquentなどに比べると最低限のORMでカスタマイズ性が高いのかなというような気がした。
Eloquentで似たようなことができないか調べてみようと思う。
AWS LambdaでPHPを動かすBrefの布教に来ちゃいました。
LambdaでPHPは動かせないがBrefを使えば動かせるようになる。
Brefというものを知らなかったので単純に勉強になった。試してみたら感想を記事にまとめようと思う。
LT会
phpinsightで技術的負債の可視化始めました
循環的複雑度✖️ファイルの変更回数でリファクタリングの優先順位付けを行なった例。
-> phpinsightを使ったことがないので試してみよう。
-> ファイル変更回数に加え変更時期とかも重み付けに加えても良さそう。
コミットを積むとは「物語を書く」ことである
phpstormのinteractive rebaseでコミット履歴を簡単に整理できるので便利。
-> interactive rebase使ってみよう。
これから始める！二段飛ばしのPHPバージョンアッププロジェクト戦略
php5.6->8.2まで一気に上げた際の例。
zendフレームワーク自体のversion upが必要だったが破壊的変更が多いためフレームワークの更新は難しかった。
部分的に修正パッチを自分たちで当てる（すごい）ことで短期間・小リソースでのversion upに成功した。
-> 自力で修正パッチ当ててフレームワーク自体の更新はしないという発想は自分の中になかったので勉強になった。
