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