15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題に直面しています。
これにより、不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になりました。

本トークでは、これらの課題を解消すべく、fuelPHP（PHP version 7.3）から社内で標準的に利用されているLaravel（PHP version 8.2）へのリプレイスを実施した事例についてお話しします。

具体的には以下のトピックについて詳しくお話しします。

• リプレイスに際して最初に決定した事項とその理由
• プロジェクトの実現可能性を高めるために考慮したスケジューリング
• 開発環境の技術選定プロセスとその選定理由
• 基本的なアーキテクチャ設計のアプローチ
• リリース時に行った対応策
• リプレイス後に得られた具体的な効果

PHPに関する深い技術的な議論は難しいかもしれませんが、技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

PHP は 1995 年から続く Web 向けプログラミング言語であり、30 周年を迎える今、技術の進化が著しい中で、PHP も大きく進化を遂げています。

PHP がこの世に生まれた頃、私はまだ 10 歳くらいの少年でした。
PHP が 30 周年を迎える今、世の中の何もかもがもはや当時とは違っています。もちろん私も 40 歳のオッサンになりました。

このトークでは以下のようなトピックへ触れつつ、2025 年の PHP プログラミングの現況を雑多な観点からまとめて紹介していきます。
・エディタをはじめとした開発環境
・今の言語機能を活かした典型的なコードの姿
・コードの部品分割方法、構成方法
・パッケージシステム
・静的解析や自動リファクタリングなどの周辺エコシステム
・実行環境の選択肢
・フレームワークの選択肢
・かつて PHP では不可能・不得意とされていた非同期処理や OS とのインタラクションなど

このトークを通じて、PHP 4 や PHP 5 の時代しか知らない人からすれば信じられないような、PHP 7 が出た 10 年前を知っている人が見ても少し意外に思うような PHP の現在の姿を知ることができるでしょう。またこれまで PHP をあまりつかったことがない人向けには、どういった言語機能やツールを前提に言語を使っていけばよいかを古い情報に惑わされずひと巡りできるような、簡単な手引となることを目指します。

皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

ScalaやErlangなどでアクターモデルは、1973年に発表された並行計算の数学的モデルの一種ですが、
長い間PHPでは実現が難しいとされてきました。
アクターモデルは、並行プログラミングにおける効率的な計算モデルであり、プロセス間の非同期通信も特徴の一つとしています
効率よくそれぞれが並行で動作し、簡単に状態を復元することができたりPHPのOSSなどではあまり見ない特徴を持っています。
PHPでももしそれが実現できたら・・・

しかし時間が経つにつれ、Swooleなどをうまく活用することで実現できそうなことがわかり、
PHPでフルスクラッチで開発したアクターモデルのツールキットがPhluxorです。

Phluxorは、PHPではあまり見られないメッセージングを活用した仕組みを持ち、
各インスタンスが独立して動作し外部から隔離されたアクターを実現しています。
さらに、物理的に異なるサーバ間でのアクター操作が可能な機能を実装しています。
Webフレームワークとは異なり、情報伝達設計に特化した仕組みを持ち、
PHPでは他に類を見ないヒエラルキー構造や自動復旧機能でアクターシステムをサポートしています。

これらは一体どのように実装して、どんな仕組みで動いているのか？
アクターモデルのツールキットの作り方について、詳しくお話します！乾杯！

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を様相論理の一種である時相論理を用いて厳密に記述し解析する技術について解説します。

みなさんは「ボタンをクリックすると機能 X が正しく動く」といったテストケースを目にしたことはありませんか？ お気づきの通り、このテストケースはあまり良くない例です。では、何が良くないのでしょう？ 一番の問題は、ここで言う「正しく」がどのような状態を指すのか、言い換えればこのテストケースが何を保証しているのか、が全く具体的ではない点です。

我々が何らかの方法でシステムの仕様を保証しようと考えた場合、テスト設計であるとか、あるいは自動化ツールのような、仕様を「テストする」ための方法論に目が行きがちです。しかしその前段階として、仕様を「記述する」というステップがあることは忘れてはいけません。入力に対して出力がある、いわゆる単体テストであればそれほど困らないかもしれません。しかし、例えば複数のサーバが協調して動く「分散システムの正しさ」だったら？ さらに、複数のサーバのうち一部が高負荷となってレスポンスを返したり返さなかったりする状況だったとしたら、全体の動作の「正しさ」にはどのような影響があるでしょうか？

自然言語による仕様の表現は、我々が普段なんとなくイメージしている以上の曖昧性を含みます。そしてその曖昧性を排してシステムに対するより良い理解と洞察を得るために、厳密な「共通言語」を定義したいという動機は、かなり旧い時代から現在に至るまで、一貫して計算機科学の興味の対象であり続けています。

本セッションでは、このような動機に応える様相論理とモデル検査について、可能な限り誤魔化さずに解説したいと思います。普段、分散システムを触っていて、何となく計算機科学の基礎が気になってきたぐらいの方にお薦めです。

私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発をしてきました
チーム文化として、クライアントニーズに迅速に応えながら、時代の変化への柔軟性を持って開発を進めることを大切にし、
常に新しい技術や手法を積極的に受け入れることを得意としていました

そんな中、話者である私自身は「サーバーレス」を得意としていましたが、そのスキルを自分ひとりの武器として振るうのではなく、
チーム全体の文化や価値観に溶け込ませ、組織的な生産性・開発価値の向上につなげるにはどうすればよいのか、日々考え続けてきました

そこで目を向けたのが「Platform Engineering」の考え方です
Platform Engineeringは、開発者がインフラやツール選定に悩まず、本質的なビジネスロジックの創造に集中できるようなプラットフォームやサービスを用意し、組織内のエンジニアリングプロセスを最適化するアプローチです
サーバーレスが得意な「私自身」から離れ、あくまで「チームとしての開発価値向上」をゴールに据え、共通のプラットフォーム基盤としてサーバーレス技術を位置づけることで、メンバー全体がその恩恵を享受できる形が見え始めました

本セッションでは、従来のLAMP系スタックを踏襲しながらもサーバーレス環境をチームにシームレスに組み込み、Platform Engineeringという視点で共通基盤として活用し続ける工夫についてご紹介します
個々人がスキルやツールに依存するのではなく、チームとして得られる付加価値、そして最終的に生まれるエンジニアリング体験の向上への挑戦についてお話できれば幸いです

• 想定聴講者
  • サーバーレスをチームに浸透させたい人
  • Platform Engineeringが何か知りたい人

近年、大規模言語モデル（LLM）が急速に進化し、ナレッジグラフとの連携が重要性を増しています。LLMは膨大なデータを処理しながらも、特定分野の知識を正確かつ構造化して扱うには限界があります。ここで注目されるのがナレッジグラフ。データを構造化し、関連性を明確にすることで、LLMと補完し合いながら、より高度なアプリケーションが実現可能になります。では、PHPでナレッジグラフを扱うにはどうすれば良いのでしょうか？

本セッションでは、PHPを使ってナレッジグラフを活用する方法を解説します。ナレッジグラフとは何か、その基礎概念から始め、具体的にPHPでどのように操作・活用するかを探ります。まず、ナレッジグラフに関連するRDF、OWL、SPARQLなどを簡単に説明し、PHPでそれらを扱うためのライブラリ（例: EasyRdfやRdfPhp) を紹介します。その後、SPARQLクエリを用いてナレッジグラフからデータを取得・操作する方法を具体例とともに解説します。

さらに、PHPで構築した既存のWebアプリケーションにナレッジグラフを組み込むためのアーキテクチャ設計や、LLMとの統合方法についても議論します。たとえば、LaravelやSymfonyのようなフレームワークを利用して、ナレッジグラフを効率的にクエリ・操作し、APIを通じて他のシステムやLLMと連携するパターンを具体例で説明します。

最後に、ナレッジグラフとLLMの組み合わせによる具体的なユースケース（FAQシステムやレコメンデーションエンジンなど）を示し、ナレッジグラフの可能性を最大限に活用するための道筋を提案します。このセッションは、ナレッジグラフという新たな分野に挑戦するための第一歩となる内容です。LLM時代の今だからこそ必要とされる技術に触れ、一緒に未来のWebアプリケーションの可能性を広げてみませんか？

「言語設定」という言葉は普段の開発でよく耳にするものの、これまで深く考えたことがありませんでした。日本語や英語などの言語設定がどのように決められ、どのように利用されているのかを理解することで、国際化対応やユーザー体験の向上にどのように活かせるのか。本セッションでは、自身が初めて真剣に言語設定の仕組みと設計に向き合った経験をもとに、言語設定の基本から設計に至るまでの学びを共有します。

まず、OS（Linux、Windows、macOS）やブラウザがどのように言語設定を決定し、利用しているのかを解説します。その後、これらの情報がPHPアプリケーションに渡されたときにどのように利用されるのか解説します。

さらに、実際のアプリケーション設計において、どのように言語の対応を処理すべきかを検討します。具体的には、Accept-Languageヘッダーを基に動的に言語を切り替えるミドルウェアの設計や、クッキーやセッションを利用したユーザー固有の言語設定の永続化方法についても触れます。また、多言語対応におけるドメインの利用（例: example.jpとexample.com）やURLパス（例: /enや/ja）を使った切り替えの実装パターンについても議論します。

このセッションは、言語設定について初めて真剣に考えるエンジニアに向けた内容です。言語設定の仕組みを理解し、設計に落とし込むまでのプロセスを一緒に探ることで、これからの国際化対応に必要な知識と視点を得られるはずです。一緒に、言語の設計に一歩踏み込み、真剣に考えて見ませんか？

技術的負債はどこの開発現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。
技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

私たちは約10年放置されてきたPHPアプリケーション（PHP5）をPHP8にアップグレードしました。
負債解消チーム立ち上げから苦節３年、メンバーの離脱もありつつもレガシーなPHPアプリケーションの移植およびアップグレードを完遂することができました。
しかしそれを終えて今、こう思うのです。なぜここまで大変になるほど放置してしまったのか―。

本発表では技術的負債はなぜ生まれてしまうのか、その組織的・構造的な問題に触れつつ、それにどう立ち向かい、そしてその後どうすべきなのか、私自身が経験したPHPの移植事例・アップグレード事例を踏まえて発表します。

話すこと

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
• 技術的負債の倒し方
• 技術的負債の倒したあと

想定聴講者

• 技術的負債の解消をしたいと思っている方
• 現在進行系で技術的負債と闘っている開発者

※本発表は PHPerKaigi 2024 で発表した「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」の完結編となります。

目の前の仕事に対して課題を見つけて、その課題に関する知識を身に着けることで社会人として十分な成長と報酬を貰えます。
たったそれだけですが、簡単ではないのです。
しかし、簡単ではない = 私には出来ないこと ではありません。

何かを犠牲にするのではなく、目の前のことを一個一個やっていくことで成長できる。
そのために必要な方法や考え方を説明します。

概要

筆者は2024年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
両者ともにPHPをメインの開発言語として置いていたのですが、「開発へのアプローチの仕方」や「PHPであること」の
意味合いはかなり異なったものでした。

例えば、以下の例

• 可読性を重視するのか、パフォーマンスを重視するのか
• 開発スピードを重視するのか、品質担保を重視するのか
• セキュリティをコードで担保するのか、ミドルウェアに任せるのか
  等々・・・

ソフトウェア開発における「あるある」でもあり、この問題と対峙している人は多いのではないかと思います。
OSS開発とWeb系Saasという2つの視点から、PHP開発における価値のあり方についてお話します。
筆者が実際に直面した課題もできる範囲でお話します。

対象者

• 開発におけるQCDSで優先順位どうするか日々悩んでる人
• 2つの宗教に挟まれた時に「どこに着地点を持っていくか」で悩んでいる人
• OSS開発のノウハウとWeb系Saas開発のノウハウを単純に比べて聞きたい方

得られるもの

• PHPのWeb開発における一つの価値基準
• 立場が変われば同じPHPでも取り組む姿勢が変わるという視点
• ソースコードとインフラの役割分担の考え方

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。

PHPによる分散処理を諦めた方は多いのではないでしょうか？
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう！

インターフェイスと聞いて何を思い浮かべますか？

プログラミング言語に備わっているInterface（オブジェクトインターフェイス）でしょうか。
それともinterface型でしょうか。
それともWeb APIのIでしょうか。
UIのIかもしれませんね。
もしかしてCLIのIですか。

本セッションのスコープとなるインターフェイスは「その全て」です。

本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスについて、出来る限りそれらの特性を明らかにしていきます。

それらを並べて見ていくと、朧げながら共通点が見えてきます。本セッションではそれを「インターフェイスという考え方」と呼ぶことにします。

本セッションではソフトウェア開発において強力な武器となる、インターフェイスという考え方について、私なりに言語化して共有します。

例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。

本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。

登壇者は現職で5年ほど、レセプト業務を扱うシステムの開発をしております。
レセプト業務はドメインが複雑でミスが許されず、また３年に一度の大きな報酬改定がありロジックがガラッと変わります。
またその改訂作業自体が非常に短期間で行う必要があり、年々と複雑化するシステムと向き合う必要があります。

その中で、ドメインに向き合い取り組んでいった結果、レセプト業務をRezept as a Serviceとして構築して報酬改訂を乗り越えることができました。
ただ最初からXaaS化しようと狙っていたわけではなく、

1. 2021年4月の報酬改訂に対応する為
2. ビジネス変化と2024年4月の報酬改訂に対応する為

上記の2回に渡って徐々にアーキテクチャを進化させていきました。
1回目のアーキテクチャ変更を経て感じた課題があり、更にビジネス上の環境の変化に対応する為にどの様にリアーキテクチャしていったのか紹介いたします。
コアドメインをX as a Service化して分かったメリットと勘所について深掘りしてお話したいと思います。

本セッションでは、次の点にフォーカスしてお話しします。

1. XaaS化までの道のり
2. なぜXaaS化を目指したのか.
   狙いと実際にどうだったのか？
3. XaaS開発における重要なポイント.
   • コアドメインの見極めと責務の明確化
   • ユーザーとのコミュニケーション設計と開発プロセス
4. 継続的な開発を通じて得られた知見.
   • 安定した開発を行うための勘所
   • コアドメインと向き合う方法、そのメリットと課題

ドメインの蒸留とはなにか？、コアドメインを切り出すとはどういうことか？の一つの事例として紹介いたします。

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話

発表者は電子工作をする訳ではないのですが、書籍『雑に作る』が大好きです！
「下手っぴでもいいから、自分なりに動くものを作るのは楽しいよ」と、ものづくりの初期衝動を思い出させてくれる一冊でした。

部品選びから始めてゼロから作るのが難しくても、 「100均の商品を分解して、中身を見てみよう！」「改造できそうなオモチャのパーツを取り出して使ってみよう！」と
簡単に取り掛かれそうなアドバイスが、とてもたくさん書かれています！

部品も既製品も、安全にさえ気をつければどう使っても良し。分解して特定の機能だけを動かしたり、組み立て直すのも楽しい。
色々なモノが動いている仕組みを、そうやって自分の目と手で理解していくことは大きな学びをもたらすでしょう。
本書ではコレを「テクノロジーを自分のものにする」と表現しています。

同じことをソフトウェアでもやってみたら、絶対に楽しいし力がつきそうですよね！
本トークでは、身近なツールを「分解」して、へっぽこガラクタを作って遊んでみた体験を共有します。

こんな人におすすめ

• 普段使っているツールに「詳しくなる」きっかけを探している
• 設計力や実装力などの地力を向上したい・勉強法を探している
• 何かおもしろソフトウェアを作ってみたいが、発明のアイディアがない!!

こんな話をします

• 分解してみる、ガラクタを作ってみるの楽しさ・学習効果
• 「やってみた」話
  • 最初はどこから読めばいいの？どう進めるの？の紹介
  • PHP製のいくつかのツールを例に、どんな「分解」「再構築」を進めていったか
• この学習方法<遊び>で、身につく力
  • コードリーディングの力
  • エッセンスを理解する、抽象的に捉える力

WindowsでPHPをビルドする場合、PHP 8.0からPHP 8.3まではVisual Studio 2019を使ってビルドしていましたが、PHP 8.4ではVisual Studio 2022の使用が推奨されるようになっています。このトークでは、Windows環境におけるPHPのビルド手順や最新情報に興味がある方を対象に、ビルドに必要な準備や実際の手順についてデモを交えて解説します。Windows版のPHPをビルドするにあたって知っておきたい情報やPHP 8.4における変更点もあわせて紹介する予定です。

皆さんはクーポンという機能について本気で考えたことはありますか？

ECサイトに限らず、グルメサイト、カラオケ、脱毛サロンなど身近な所にあるクーポン。日常的に何気なく、気軽に使うことが多いと思います。けど、実装するとなると、実は考えるべきことが多いです。

「x円以上だと適用可」「おもちゃに対して適用可」のようなクーポン自体の適用条件もあれば、予約、出荷(おまとめ)、価格変更など、クーポン以外の仕様も絡んできます。その辺りの考慮が満遍なくできていないと、複雑さのあまりのちのカスタマイズで死亡します。私は悲しみに包まれました。

このセッションでは、主にECの開発者向けにクーポンという機能を実装する際に考えておくべきこと。そしてどのようにクーポンを設計すべきか？について実際に痛い目を見た私が熱く語りたいと思います。

"君も幸せについて考えてみてよ 後で答え合わせしよう 少しはあってるかなぁ？"

「オブジェクト設計スタイルガイド」は、オブジェクト指向プログラミング（OOP）の設計と実装におけるベストプラクティスを網羅した優れた書籍です。スタイルガイドという名前の通り、明日からすぐに実践できる内容であるため、オブジェクト指向の基礎を理解している開発者にとって有益な参考書です。

本セッションでは、まずオブジェクト指向設計の基本概念を確認し、その後に書籍の具体的なコーディングスタイルを紹介していきます。以下はテーマとコーディングスタイルのサンプルです（番号は書籍によるものです）。

・2.1 2種類のオブジェクト
→ サービス層とドメイン層の役割とその違い（オブジェクトを呼び出す側と呼び出される側）
・2.3 サービスロケータを注入するのではなく、必要なもの自体を注入する
→ 依存性注入（DI）

・4.1　エンティティ：変更を追跡し、イベントを記録する識別可能なオブジェクト
・4.2　バリューオブジェクト：置き換え可能、匿名、イミュータブルな値
→ エンティティとバリューオブジェクトの設計（ミュータブル／イミュータブルの設計指針を含む）

・6.7　クエリメソッドからはコマンドメソッドは呼び出さず、ほかのクエリメソッドのみを呼び出す
・7.5　情報を収集するためにクエリを使用し、その次のステップに進むためにコマンドを使用する
→ CQS（コマンドクエリ分離原則）の基本と実践

本セッションを通じて、開発者がOOPの原則を理解し、それを適切に活用する知識を提供することで設計力の向上を目指します。

なお、本発表は「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」という発表を、より PHPer 向けに深掘りしたものです。
https://speakerdeck.com/panda_program/no-more-lightweight-ddd