Shin x Blog

PHPをメインにWebシステムを開発してます。Webシステム開発チームの技術サポートも行っています。

「ドメインをモデリングして PHP コードに落とし込む」を発表しました / PHP カンファレンス 2021

2021/10/02, 03 にオンラインで開催された PHP カンファレンス 2021 にて「ドメインをモデリングして PHP コードに落とし込む」を発表しました。

発表資料

ドメインモデルという共通概念をモデリングし、それをコードに反映するという内容です。

去年は事前に録画して自分で再生した のですが、今年はライブでやりました。やっぱりライブは良いですね。話し出しはモニタに向かって話す違和感がありましたけど、途中から調子が掴めてきました。

Discord をチラ見していたのですが、リアルタイムでどんどんコメントが流れていたおかげで発表している実感が得られました。その場でコメントを見ることができると伝わっていることが分かり、ある意味リアルな会場で話すよりも感触が得やすい面もありました。おかげで楽しく話すことができました。参加していただいたみなさんありがとうございました!

DDD パターン名を使わない

個人的なテーマがこれでした。

今回の内容であれば DDD のパターンを用いて説明することもできました。例えば、境界づけられたコンテキストやユビキタス言語の話をし、モデリングし、値オブジェクトやエンティティ、集約と実装パターンといったぐあいです。ただ、こうしたパターンは分かっている人には話が早いのですが、そうでない人にとってはただパターン名を追いかけていくことになり、なぜそれを使うのか、どういった効果を狙っているのか、そして各パターンがどう繋がっているかといった本質的な理解に結びつきにくい印象があります。

実際、パターンは覚えたけどそれをいかに使うかに力点が置かれすぎたり、パターンの数に圧倒されて DDD を敬遠するというケースを見聞きすることもありました。過去の自分も含めて、DDD パターンに振り回されている人が多い印象があったので、今回の発表ではそういったパターンには触れずに、用語集や簡略化した UML、そして OOP といった身近な手法で実践できることを伝えるようにしました。

当たり前ですが、パターンにはそれを利用する目的があり、それを達成できるのであれば手段は他のものでも構わないわけです。

念のため補足しておくと、DDD やそのパターンは有用なものです。今後も多いに参考にするでしょうし、パターンも利用していきます。また、それを伝えるアプローチとしてパターンを解説するのも良いと思っています。ただ、今回の発表というコンテキストにおいてはこういう考えで作ったということです。

コードから想起される概念

f:id:shin1x1:20211005140222p:plain

このスライドは、業務さんと開発 A さんとの間では円柱という共通概念を共有できているのですが、コードには円柱の特徴である「上から見ると丸」と「横から見ると四角」を別々に実装しています。このため、コードを読んだ開発 B さんは丸と四角という概念があると想起してしまうというものです。異なる認識を元にコードを読むことで理解が難しくなったり、誤った変更をしてしまうケースがあります。だからこそドメインモデルをコードで表現しましょうという話に繋がります。人同士の持つ概念だけでなく、コードから想起する概念があるということは大切だと考えているのでそこが伝わるとうれしいです。

反応をいただいたトピック

多くのコメントをいただいたのですが、その中のトピックについてです。

用語集

プラクティスとして良く知られているものの、現場では意外と作られていないのが用語集です。この重要性をあらためてお話ししました。共通概念を作るという意味では第一歩目というべきものだと思ってます。実際、これをやるだけでいかに自分たちが異なる概念を抱いているかを再確認できますし、用語とその意味を定めるという経験によって言葉に対して意識を持ってもらえるというのも大きいです。開発チームだけでなく、業務チームと一緒に整理してみるのがおすすめです。

いくつかコメントで反応いただいていましたが、英訳を含めておくと実装時に人によって英訳がまちまちで、英語は異なる表現だけど実は同じ概念を指していたということを防げるので良いです。

UML

発表の途中で UML を書いたことがあるかについて質問をしてみました。コメントをざっくり拾うと 9 割の方は書いたことがあるが、その中で日常的に書く人書かない人は半々といったところでした。UML の活用シーン(UML でレビューしてから実装する、納品物に含める、シーケンス図のみ使うなど)もコメントいただいたので参考になりました。

発表のとおり、私自身は UML は概念を特定の視点で整理したり、表したりするものという観点で利用しています。正直、UML である必要はあまりなく、他に良いものがあればそちらでも良いのですが、現状、ある程度共通認識として利用されており、ツールも発達しているので便利に使わせてもらっているという感じです。そういえば、業務サイドの方との共有では UML そのままというよりは表現を変えて提示したりもしますね。

UML というと昔の厳密で厳格なイメージもあるかもしれませんが、ことツールという観点では気軽に使えるので、思考を整理したり、共有したりするのにスケッチする目的で使うのも良いと思います。このようにスケッチ UML で必要な最低限の記法だけをまとめたコンテンツがあれば、UML を知っている人も気軽に使えて、これからの人もそれだけ参考にすれば書けるので良いかもしれませんね。

日本語コード

f:id:shin1x1:20211005140457p:plain

ドメインモデルの実装には日本語を利用していたので、それについてのコメントもありました。私自身も試してみるまでは、動作は大丈夫なのか、入力や補完が面倒そう、そもそも読みやすい?など色々と考えていました。もちろんコンテキスト(そもそもドメインが日本語表現なのか、開発チーム構成などなど)は選びますが、上手く合うなら、かなり分かりやすいと思います。実際、プロダクションコードに日本語を利用しているプロダクションもあります。まだ書いたことが無い方は、自分たちのプロジェクトのドメインについてサンプルコードを書いてみてください :)

さいごに

ドメインをモデリングして実装という一連の流れをお話することができて良かったです。上述したように目新しい手法、難しい手法を使わないといけないわけではなく、良く知られた方法を使うことで実践できることが伝わっていればうれしいです。*1 用語集を作ってみよう!というコメントもいくつかあったので、まずはできるところからトライしてみてください。実践した上で、エバンス本などの DDD の書籍や資料に触れていくとより理解が進んでいくので、興味がある方はこうした文献にも目を通してみてください。

これまで頭の中にあった概念を発表という形で表現できたので、機会があればまたどこかで話してみたいですね。

今年は 2 days だったおかげで、1 日目の発表が終わったあとの 2 日目はのんびりセッションに参加できました :) 毎年ながらですが、今年も素晴らしい PHP カンファレンスをありがとうございました!

*1:もちろん、より複雑な問題を扱ったり、継続していく難しさはありますけど