恣意性から考える、変更に強いモデルの作り方

PHP Conference 小田原 2025 での発表です
https://phpcon-odawara.jp/2025/

Transcript

1. 恣意性から考える 変更に強いモデルの作り方 PHPカンファレンス小田原 2025
2. 名前: 吉田あひる (@strtyuu) 仕事: エンジニア 所属: スターフェスティバル株式会社 自己紹介 おいラジオ
3. 今日お話しすること • ドメインモデルの変更コスト • 恣意性とはなにか • 恣意性が設計にどう活きるのか
4. おことわり N = 1 の個人的な見解・主観が強い内容になっているため、鵜呑みにしないことをおすすめします
5. ドメインモデルの変更コスト
6. ドメインモデルは構造的に変更コストが高い • アーキテクチャの中でも中心にいることが多い • そのため、多くのコンポーネントから依存される対象になる • 依存が集中すると、変更コストが上がる
7. 意図的にドメインモデルへの依存は増やされている • 全ての依存を小さくすることは難しい • そのため、どこかのコンポーネントは依存が大きくなる • 安定要素とみなされているビジネスロジックの実装先であるドメインモデルに依存を集中させることで、 トータルの保守コストの低下を狙っているはず
8. 「ビジネスロジックは安定している」は本当か • 実際には変更されやすいものも含まれているように思う ◦ 特に、ビジネス的なポリシーが反映されているものなど ◦ 値引きキャンペーン、有料機能、 etc • 「ビジネスロジックは安定している」の前提が部分的に崩れるため、取り扱いを間違うと保守性のリスクに 繋がる
9. 変更されやすい要素にどう備えるか？ • DDD の「深いモデル」はこういった問題の回答の一つであると思われる • この問題について自分なりに言語化をして登壇しました ◦ さいきょうのレイヤードアーキテクチャについて考えてみた ◦ https://speakerdeck.com/yahiru/saikiyounoreiyadoakitekutiyanituitekao-etemita • ざっくりまとめると ◦ 変更されやすい部分を抽象化し ◦ Open/Closed の原則に準拠する ◦ こうすることで、ドメインモデル自体を変更する頻度を低減させることができるのではないか
10. 変更されやすい要素とはどこなのか？ • そこの予想が難しくて苦労してるんですが ...! • 当時の発表では言語化しきれなかった
11. 恣意性
12. 恣意性とは 論理的な必然性のないこと
13. 恣意的な仕様は変化が起こる可能性が高いのでは？ • 「こうでなければいけない」理由があまりない • 他の選択肢もありえる • 「こうでなければいけない」ではなく「今はたまたまこうしている」仕様は、変更の可能性が高いという見方 ができるのではないか？
14. Tweet の文字数は 140文字まで • 140という数字にどこまで論理的な必然性があるんだろう？ • 2017年11月に半角文字であれば280文字まで可能に ◦ 実際の Tweet の 9% が140文字いっぱいまで使われていることからユーザー自身の表現を制限してしまってい るのではといった仮説のため • 現在では有料ユーザーであれば長文のポストが可能に ◦ マネタイズのポイントなどビジネス的な文脈でも変更が起こる
15. Slack フリープランで閲覧可能なメッセージの条件 • 「どの条件であれば閲覧させるか」自体が恣意的に感じる • 当初は1万件のメッセージまで • 現在では過去90日間のメッセージのみ閲覧可能
16. Amazon 送料無料の条件 • すべて送料無料の時期も • 地域や購入金額に応じた条件判断 • 有料会員であれば送料無料 • 事業環境や財務状況、マーケティング的な文脈など様々な観点から変更が起こりそう
17. 恣意性の活かし方
18. 不安定さのシグナルとして考える
19. 不安定さのシグナルとして考える 「論理的な制約ではなく、なんとなくそうなっているだけでは？」という感触があれば、そこに対して抽象化すべき かどうかを検討する判断材料として役立つのではないか
20. 申請機能での実例 • 申請とそれに対する承認などを行うことができる機能 • 「申請に対して三次審査まで実施したい」という要件に恣意性を感じた • 審査ステップ数を変えることができたら、どんな嬉しいことがありそうだろうか？ ◦ 運用体制の変更に合わせた審査ステップ数の削減 ◦ 誰が申請するかによって審査ステップを減らす ◦ といった運用コストの最適化などができそう • n次審査が可能なモデルとして実装 • 結果、申請種別ごとに審査ステップ数を変えたいという新しい要件が後から発生し、モデルを変更せずに 対応できた
21. とはいえ全ての恣意性に備えればいいわけではない • 恣意性を感じたところ全てを抽象化するのは当然 YAGNI になる可能性が高い • 恣意性に備える対応を後回しにした場合の追加コストや、ビジネス的な観点からどの程度変更が起こり そうかといったことを想像して、都度現実的な判断をしていくのが無難
22. ドメインモデルから 関心を分離する根拠として考える
23. なぜ関心を分離したいのか • クラスや関数に対して変更が発生するのは、変更対象がその変更に対して関心があるから ◦ ノーコードツールは高度に抽象化されているため各企業の業務の詳細に関心がない ◦ そのためノーコードツール自身のドメインモデルをいじらずに業務の変更に対応できる • そのため、ドメインモデル自身の関心を減らすことができれば、変更が起きにくいドメインモデルの構築に つながるのではないか
24. 整合性に関する関心
25. 2つの強整合性 • 強整合性とは... ◦ 常に全体で矛盾のない状態を即時に保つこと ◦ 結果整合性の逆 • 恣意的な強整合性 ◦ 強整合性ではあるが、仕様の変更によって変わってしまってもよかったりする ◦ 整合性が破られても大きな影響がなかったりする ◦ 例: Tweet は140文字までだったが仕様変更によって 280文字や長文も許可された • 恣意的でない強整合性 ◦ ドメインモデルとしての振る舞いを維持するのに必要な整合性であることが多い ◦ 例: 注文ステータスは特定の値以外許容されないなど ◦ 他のロジックがこの整合性が担保されていることを前提としていることがある
26. 恣意的な強整合性を関心から外してもいい可能性 • 変えてしまってもいいものをドメインモデルでガチガチに守らないといけない理由もないのでは ◦ ゆるく構えておいた方が、変更が楽なのでは • また、整合性は全てドメインモデルに担保させなければいけないと考えてしまうと後方互換性のない整合 性の変更があった場合に不自然な構造になることもあるのでは • であれば、自然な構造が維持できなくなってきた場合はドメインモデルの関心から外してしまった方が合 理的な可能性が高い
27. 過去のデータに制約 をかけられないパ ターン
28. 状況に応じて整合性 が変わるパターン （この例だとこんな書き方をする人はあまりい ないかもしれないが...）
29. 複数の整合性が同居してもいいのか？ • 同じ概念なのに状況に応じて挙動が変わる ◦ 状態の一貫性・本当に守らなきゃいけないラインが見えにくくなる • どの整合性の上になりたっているのかわからない状況にどこまで意味があるだろうか • 状況に応じて無視していい制約を守らせる意味はどこまであるだろうか • バリデーションロジックのみドメインモデルとして提供して、それを適用するかどうかはユースケースの関 心とした方が自然じゃないか
30. ドメインロジックと アプリケーションロジック
31. 何がドメインロジックなのかの認識がブレる問題 • アプリケーションがなくても存在するものがドメインロジック ◦ Twitter みたいなアプリケーションありきのサービスだと何がドメインロジック ...? • ビジネス上の重要な関心を表現するのがドメインロジック ◦ 重要とは...?
32. Findy はマッチしないとやりとりができない • Findy という転職サービスは、企業とユーザーがマッチしないとメッセージを送れない ◦ 一見するとドメインロジック感もあるが、多少恣意性も感じる • しかしどこかのタイミングで実装されたプレミアムスカウトという機能ではマッチしなくても企業からスカウト を送ることができる • つまり、マッチしないとやりとりが開始できないという仕様はユースケース依存のアプリケーションロジック だったといえそう
33. 恣意的なものはアプリケーションロジックと呼べるのでは • 恣意的な仕様はユースケースごとに変わっても論理的には問題ないためユースケース依存と考えられそ う • であれば、アプリケーションロジックとして考えて問題ないのでは
34. まとめ
35. まとめ • 変更に強いモデルを作るには変更のおきやすい箇所に対して「関心の分離」や「抽象化」を行うのが効果 的ではないか • 変更のおきやすい箇所を見つけるための思考ツールとして「恣意性」が使えるのではないか • 恣意性はドメインロジックかどうかの判断材料としても使えるのではないか • 恣意性でゴリ押ししてみたけどどこまで良い線いってるんだろうか
36. We Are Hiring !!