遅くなりましたが、PHPerKaigiに行って聞いたセッションについて感想書きます。
ブログ書くまでがカンファレンス！って言われてるので。
カンファレンス全体の雰囲気に関する感想はこっちに書いてます。
https://qiita.com/GreenGreeen/items/833fc6ca0e420271367f
day0
Mr.Logicの例え話がわかりやすかった。
また、個人的にもEloquentはインフラ層にとどめてドメイン層へは持ち込みたくない派で、
過去にDTO作るのとEloquentのメリットがないって言われ、う〜んとなったことがある。
発表でもEloquentはインフラ層にとどめた方がいいという話だったので、自分の感覚が間違っていないと安心した。
インフラ層の例外をユースケースでハンドリングしてはいけないという話もあったって、最近自分がやってしまった気がしたので、サービス層やドメイン層に持ってこないためにも専用例外作るようにしよう。
trait使って管理画面のコードを作れば検証不要になるのはありがたい。
でもそれぞれのユースケースであれがしたい、これがしたいという要望が出て単純にはうまくいかないケースが増えてきそうなので、
どこまで共通化できるのかはサービス次第だなと思う。
day1
このセッションは人気すぎで会場に入れなかったので、シフト録画で見た。
モジュラモノリスを採用しているので、かなり興味があった。
モジュラモノリスで分散自律的なチームを目指したものの、
ビジネスでは顧客価値検証が優先されるため、
モジュール単位のチームから機能横断のチームに組織編成されていったらしい。
自分も、モジュラモノリスの場合はモジュール単位のチームが破綻しやすいように感じている。
現場でもモジュラモノリスで開発しているが、担当者不在の機能があったりと、
正直うまくいっているとは言いづらい状況。
モジュラモノリスはマイクロサービスに比べて分割しやすい分、
適切に分割されていないと結局モジュールをまたいでコード変更が必要になるし、
モジュール単位でリリースできない場合、リリース調整などの仕事が発生して開発が遅くなってしまう。
また、担当意識の低下も、マイクロサービスに比べると発生しやすいように感じる。
とはいえマイクロサービスの場合は、担当チームは明確になるものの、
チーム間のコミュニケーションコストが高くなったり、
一部のマイクロサービス開発が詰まる可能性もある。
このあたりの正解はまだ分かっていないが、
モジュラモノリスのメリットを享受しつつ、今抱えている課題にどう対応していくかを考えていきたい。
day2
どの話も経験があることだったので、すごく共感しながら聞いていた。
ドメインサービスを作ると何でも入れたくなって、
ドメイン貧血症になりやすいのはあるあるだと思うし、
ちゃんとポリシーを設定しているのはいいと思った。
そのポリシーが読みたい！！
DBスキーマ変更も、最近自分がALTER実行で障害を起こしたばかりだったので、
身につまされる話だった。
pt-oscは知らなかったけど、自分の関連するドメインがマルチドメインなので、
そのままは使えないのかも。
とはいえ、判断と手順を自動化する重要性はわかるので、
これから自分も頑張りたい。
まだ見てないセッション
気になっていてまだ見てないセッションやバンプレット寄稿記事も読み終わってないので、見たら追記します。