Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
検索条件にCRITERIAを
Search
ICKX
May 31, 2025
Programming
99
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
検索条件にCRITERIAを
ICKX
May 31, 2025
More Decks by ICKX
See All by ICKX
AIの揺らぎに“コシ”を与える階層化品質設計
ickx
0
700
Symfonyの特性(設計思想)を手軽に活かす特性(trait)
ickx
0
210
階層化自動テストで開発に機動力を
ickx
1
990
「兵法」から見る質とスピード
ickx
1
610
あなたの知らない新潟
ickx
0
120
香川にはTyrellがあるからね
ickx
0
470
品質が高いコードって何?Rev2.1
ickx
2
1.2k
品質が高いコードって何?
ickx
7
5.1k
【PHPerKaigi2021】PHPでCSVを安心して扱うために
ickx
4
3.4k
Other Decks in Programming
See All in Programming
Event is what happens
moro
2
1.2k
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
160
なぜCTOを降りてFDEを選んだのか?〜なぜプロダクト企業がFDEで顧客の現場に踏み込むのか〜
gonta
1
230
Groovy as a human and AI friendly programming language
paulk
0
100
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
360
3回つくってわかった、 定期実行ジョブ基盤の本質情報
takai
0
600
AI主導のプログラミング学習アプリを作ってみた
econanringo
0
180
Kotlinの15年とServer-Side Kotlin
n_takehata
1
160
ActionController meets Protocol Buffers
sorah
0
660
機械に任せるテスト、人が見るテスト ⽣成AIで引き直した、運⽤保守フェーズの線引き
dske104
0
200
Findy - エンジニア向け会社紹介/Findy Company Deck
findyinc
6
400k
AWSに止められる覚悟してますか?
morizo_1984
2
540
Featured
See All Featured
Odyssey Design
rkendrick25
PRO
2
880
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.3k
The untapped power of vector embeddings
frankvandijk
2
1.9k
Chasing Engaging Ingredients in Design
codingconduct
0
370
Testing 201, or: Great Expectations
jmmastey
46
8.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
1k
The Invisible Side of Design
smashingmag
301
52k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
570
How STYLIGHT went responsive
nonsquared
100
6.3k
Scaling GitHub
holman
464
140k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
Transcript
検索条件にCRITERIAを 同人ソフトサークル Project ICKX 若葉 章 @effy_staffs (EFFY開発チーム)
検索をパターン化する CRITERIAパターン(造語)の ご紹介
状況! • これは部屋単位の予約システムです • 部屋の予約は次の三要素で成立します • 予約日 • 部屋番号 •
顧客ID • 指定する予約日と部屋番号でリソースに アクセスしたいです
ほーん、ならまずはVoこうするか
Entityはこうやな
URLの構築はこうやな Symfonyの場合、 URLパスパート上の変数名と ここのキー名が完全一致する 必要がある 年月日なので フォーマットを 整えるっぴ
検索はこうやな Doctrineかつスキーマ定義で Datetime型を指定している場合、 Datetime型を与える必要がある 設定次第だがDoctrineの場合 プロパティ名を lowerCamelCaseに する必要がある
似たような検索が出るたびに こうちまちま弄るのめんどくさいな
具体的には・・・ • 全ての検索箇所、URL構築箇所においてそれぞれのエンティティの 特性に合わせたプロパティ名の書き換えが必要 • 検索とURL構築でコンテキストが異なり、コンタミネーションすると 事故につながる 今回は たまたま 同じ
検索条件にCRITERIAを
まずはエンティティを抽象的に扱えるように
検索条件インターフェースの用意 • 全ての検索条件はcriteriaアクセサーを持つ • 本例においてPHP8.4からの非対称可視性プロパティフックで実装 しているのは責務を明確にしたいから
ドメイン層としての検索条件インターフェースの用意 • ドメイン層なのでドメインエンティティからの変換が可能 • 一度ドメイン層として”検索条件”を一般化する事で、 アプリ層などの他階層での関心毎を減らす
アプリ層としての検索条件インターフェースの用意 • ドメイン検索条件として検索条件を受け入れる事でシステム全体の 検索条件を明確にする • アプリ層として検索条件の受け入れ方を一般化し、どのような特性 であっても同じ手触りを提供させる • 合わせて、共通項は自動化もさせる
アプリ層としての検索条件特性の用意 • アプリ層としての検索条件の特性を抽出し、以降の実装での考え事 を減らします
特性に応じた検索条件インターフェースの用意 • 検索特性に応じた検索条件インターフェースを用意することで 知識のコンタミネーションを防ぐ ※URLって書いてあるんだからURL用の結果が返るのは自明
検索条件にCRITERIAを
ドメイン検索条件 • ドメイン知識としての 検索条件が明快になった • 要求を全て満たしている ので高品質 • 予約日と部屋番号で リソースにアクセス
• 要求の確認対象が明確かつ 最小なので、検証しやすい • ドメイン層としての コンテキストを持つため 利用側での自律動作を 実施しやすい(後述)
アプリ検索条件(repository) • アプリ検索条件インターフェースがそのまま使われる事はないです • このリポジトリ検索に 必要なコンテキストだけを 考えれば良くなっています • 今回はVOが持つ情報が 1:1で適合しているので
get criteriaでは変換なし
アプリ検索条件(url) • このURL検索に 必要なコンテキストだけを 考えれば良くなっています • リポジトリ側と違って こちらではコンテキストに 依存した変換を行って います
• これが利用側における 自律的な動作です • 十分なコンテキストを 与えられているため 必要ならクラス名を元に 完全自動変換すら可能です
検索条件がCRITERIAに
検索 • これだけで済むようになっちゃった • 以降、検索条件が変わったとしてもcriteria群を弄るだけで 利用側のコードを変更する事はありません (それ以前にクラスとして用途が明確になっているので変更される 事はまず起きえないんですが)
URL構築 • URL検索条件インスタンスを直接与えられるならこれで済むように なりました • リポジトリ検索条件とインターフェースが同一なため、ドメイン 検索条件を修正し、アプリ検索条件が追随すれば自動的に全体の 協調が取れます
URL構築 • ただまぁ流石に繰り返しの中などでは利用できないので、twig拡張 を用意した方が良いです • twig拡張の例
URL構築 • 拡張がある前提ならばこのような記述が可能となります • 単数であっても次の通り • 例によってパラメータが変わったとしても実際に利用する側の変更は 不要となりました
おしまい