こんにちは、スターフェスティバル株式会社の吉田あひるです。
M&A クラウドさんによるPHPerKaigi2022 に 8 人全員で合計 12 個のプロポーザルを提出しました という記事が素晴らしかったので、弊社からもPHPerKaigi 2022に提出した 4 つのプロポーザルを紹介させていただきます！
PHPerKaigi とは
PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在 PHP を使用している方、過去に PHP を使用していた方、これから PHP を使いたいと思っている方、そして PHP が大好きな方たちが、技術的なノウハウと PHP 愛を共有するためのイベントです。
PHPerKaigi 2021 より
弊社スターフェスティバル株式会社はゴールドスポンサーをさせていただいております！
僕も毎年個人的に参加させていただいており、今年の開催もとても楽しみです。
プロポーザルの紹介
投稿順に紹介していきます。
愉快な Event Sourcing アンチパターン
弊社のリアクティブシステムお化けである ytake さんによるプロポーザルです。
ytake さんの豊富すぎる経験に基づくアンチパターンの話、めちゃくちゃウケそうなので是非聞きたいですね！
Event Sourcing は CQRS との組み合わせだけでなく、そのエッセンスは様々な仕組みに取り入れることができます。
マイクロサービスアーキテクチャ化、大規模なデータ処理の改善、
リアクティブシステム構築などではほぼ必須のテクニックとなりますが、
ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
分割しすぎて時系列を無視したイベントなどなど。
いくつかは実際にやってしまったこともありますが、体験や例をもとに
Event Sourcing とは何かを説明しながら、何をすべきでやるべきでないのかを楽しくお伝えします
入門 境界づけられたコンテキスト
設計お化けでもある ytake さんによる 2 つ目のプロポーザルです。
アプリケーションを設計をする上で避けられない、でもよくわからなくて難しい「境界づけられたコンテキスト」ですが、このトークを聞くとなんと入門できちゃうようです！
個人的に今回の推しプロポーザルなので是非採択されてほしいです。
モデルという言葉から皆さんはどんなものを想像しますか？
我々の日常生活やエンジニアチーム、エンジニア以外のチームとのコミュニケーションでは、
耳に入る言葉にはそれぞれコンテキストが多分に含まれています。
コンテキストを理解せずにそれぞれのチームが微妙に異なった認識で物事を進めると、
どんなことになってしまうのでしょうか？！
コンテキストを正しく理解することは、その時の仕様を満たすシステムを作るだけではなく
うまく活用することでビジネスを加速させるためのコミュニケーション改善や、
複雑な仕組みを解決する力となります。
より良いシステムづくりのためにも是非入門してみましょう！
設計におけるソリューションドメイン
最近マルチパラダイムデザインという本に感動した僕のプロポーザルです。
ソリューションドメインって何！ってところから、ソリューションドメインを学ぶと設計にどのような影響があるのかみたいな話をする予定です！
ソリューションドメインという単語をご存知でしょうか？
ソリューションドメインとは PHP のようなプログラミング言語や MySQL のようなデータベースといった技術に関するドメインですが、ソリューションドメインに関する知識が少ないと、不必要な複雑さをアプリケーションに持ち込んでしまったり、適切でないモデルを構築するハメになってしまうことがあります。エンジニアであれば技術の勉強を通してソリューションドメインへの理解を深めているはずですが、このトークでは改めてソリューションドメインについてまとめたいと思います。
- ソリューションドメインとは何なのか
- 設計とソリューションドメインの関係性
- ソリューションドメインを学ぶことで設計にどのような影響があるのか
- どのような問題ドメインに対しては PHP を使わない方がいいのか
ユースケースから考えるデータベースのテーブル設計入門
弊社のデータベースお化けである ikkitang さんによるプロポーザルです。
ikkitang はテーブル設計をリードしまくってくれているめちゃくちゃ頼もしいメンバーなのですが、このトークで ikkitang の強さの秘訣がわかるかもしれません。
致命的な問題が起きにくいテーブル設計、できるようになりたいですね！
昨今、RDBMS を用いてサービスを作ることは非常に多くあると思います。
堅牢なテーブル設計を行っておく事は非常に重要で、バグが生まれづらくなったり仕様変更にも強いなど得られる恩恵は多いです。
逆に複数の関心事が集まったテーブル設計を行ってしまった結果、データを取得する為の SQL がややこしくなったり、仕様変更に弱くなる事も多くあります。アプリケーションと比べてデータベースは寿命が長く、その頃にはリファクタリングすら着手する事が難しいという事も多いですよね。本セッションでは、データモデリングを学んでいなくても致命的な問題が起こりづらいテーブル設計手法について大規模 Web サービスの DB リファクタリングをやった経験を踏まえて紹介させて頂きたいと思います。
終わりに
並べてみると全て設計に関するプロポーザルだったことに気がつきました。
そして全員 PHP の話をしそうにないことにも気が付きましたが、採択されることを祈っております！
また、弊社からのプロポーザルは以上ですが、そのほかにも面白そうなプロポーザルがたくさん提出されているので、興味がある方は是非眺めてみてください。
そして、面白そうだと感じた方はプロポーザルのスターを押したりチケットを買ったりして PHPerKaigi を盛り上げていきましょう！
Discussion