Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
検索条件にCRITERIAを
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
ICKX
May 31, 2025
Programming
0
66
検索条件にCRITERIAを
ICKX
May 31, 2025
Tweet
Share
More Decks by ICKX
See All by ICKX
階層化自動テストで開発に機動力を
ickx
1
760
「兵法」から見る質とスピード
ickx
1
470
あなたの知らない新潟
ickx
0
70
香川にはTyrellがあるからね
ickx
0
360
品質が高いコードって何?Rev2.1
ickx
2
1k
品質が高いコードって何?
ickx
7
4.7k
【PHPerKaigi2021】PHPでCSVを安心して扱うために
ickx
4
3.2k
【PHPerKaigi2020】ぼくのかんがえたさいつよQueryBuilder
ickx
0
1.1k
【PHPカンファレンス関西2018】遅延評価戦略を用いたアクション呼び出しと安全なコピペで生産性アップ!
ickx
0
770
Other Decks in Programming
See All in Programming
コントリビューターによるDenoのすゝめ / Deno Recommendations by a Contributor
petamoriken
0
210
開発者から情シスまで - 多様なユーザー層に届けるAPI提供戦略 / Postman API Night Okinawa 2026 Winter
tasshi
0
210
HTTPプロトコル正しく理解していますか? 〜かわいい猫と共に学ぼう。ฅ^•ω•^ฅ ニャ〜
hekuchan
2
690
登壇資料を作る時に意識していること #登壇資料_findy
konifar
4
1.7k
izumin5210のプロポーザルのネタ探し #tskaigi_msup
izumin5210
1
140
AgentCoreとHuman in the Loop
har1101
5
250
Lambda のコードストレージ容量に気をつけましょう
tattwan718
0
150
フロントエンド開発の勘所 -複数事業を経験して見えた判断軸の違い-
heimusu
7
2.8k
MDN Web Docs に日本語翻訳でコントリビュート
ohmori_yusuke
0
660
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
1
750
疑似コードによるプロンプト記述、どのくらい正確に実行される?
kokuyouwind
0
390
OCaml 5でモダンな並列プログラミングを Enjoyしよう!
haochenx
0
140
Featured
See All Featured
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
0
190
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
79
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
57
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.4k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
BBQ
matthewcrist
89
10k
Context Engineering - Making Every Token Count
addyosmani
9
670
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Code Review Best Practice
trishagee
74
20k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
330
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
1.9k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
1
1.3k
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構築 • 拡張がある前提ならばこのような記述が可能となります • 単数であっても次の通り • 例によってパラメータが変わったとしても実際に利用する側の変更は 不要となりました
おしまい