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
さいきょうのレイヤードアーキテクチャについて考えてみた
Search
y_ahiru
January 31, 2025
Programming
3
850
さいきょうのレイヤードアーキテクチャについて考えてみた
吉祥寺pm 37 での登壇資料です
https://kichijojipm.connpass.com/event/339040/
y_ahiru
January 31, 2025
Tweet
Share
More Decks by y_ahiru
See All by y_ahiru
恣意性から考える、変更に強いモデルの作り方
yahiru
0
230
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
10
1.9k
フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
yahiru
16
13k
ゆるふわCQRS入門
yahiru
2
630
設計におけるソリューションドメイン
yahiru
3
1.6k
PHPで始めるGitHub Actions
yahiru
1
760
5ヶ月でカバレッジを20%から90%にあげた話
yahiru
2
6.7k
入門ミューテーションテスト/ A bigginer's guide to Mutation testing
yahiru
0
1.5k
Eloquentに別れを告げるタイミングについて考えた
yahiru
2
2k
Other Decks in Programming
See All in Programming
SwiftUI API Design Lessons
niw
1
260
生成AIを使ったQAアプリケーションの作成 - ハンズオン補足資料
oracle4engineer
PRO
3
190
サービスレベルを管理してアジャイルを加速しよう!! / slm-accelerate-agility
tomoyakitaura
1
160
remix + cloudflare workers (DO) docker上でいい感じに開発する
yoshidatomoaki
0
130
タイムゾーンの奥地は思ったよりも闇深いかもしれない
suguruooki
1
540
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
1.2k
Building a macOS screen saver with Kotlin (Android Makers 2025)
zsmb
1
140
ベクトル検索システムの気持ち
monochromegane
31
9.8k
Ruby's Line Breaks
yui_knk
2
460
AIコーディングワークフローの試行 〜AIエージェント×ワークフローでの自動化を目指して〜
rkaga
2
3.3k
Django for Data Science (Boston Python Meetup, March 2025)
wsvincent
0
320
SEAL - Dive into the sea of search engines - Symfony Live Berlin 2025
alexanderschranz
1
120
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
52
7.5k
Building Applications with DynamoDB
mza
94
6.3k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
BBQ
matthewcrist
88
9.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.4k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
660
Done Done
chrislema
183
16k
Into the Great Unknown - MozCon
thekraken
37
1.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
178
52k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
640
Transcript
さいきょうのレイヤードアーキテクチャ について考えてみた 吉田あひる @吉祥寺.pm37
名前: 吉田あひる (@strtyuu) 仕事: エンジニア 所属: スターフェスティバル株式会社 自己紹介
なぜこんな話をしようと思ったのか
ビジネスロジックをドメイン層に実装 するって正しいんだっけ?
なぜそんな疑問を持ったのか • ドメイン層は大体一番下の層として配置されている • ドメイン層にビジネスロジックを実装するという話はよくきく • でも、ビジネスロジックって普通変わっていくもの ◦ 少なくとも、ビジネスロジックと言われるものの中には安定度の低いものがあるはず •
安定度の低いビジネスロジックがドメイン層に入っているのは影響範囲が広くなりがちであまり嬉しくない んじゃないか?
ぼくのかんがえた さいきょうの解決策
変更要求がきたら
ドメイン層の手前で吸 収できると理想なの では?
どうすればドメイン層の手前で 変更要求を吸収できるか?
ノーコードツールが参考になるのでは? • コードを書かなくとも簡易的なアプリケーションを作成できるすごいやつ
ノーコードツールはドメインモデルをいじらない • ノーコードツールを使ってビジネスや業務を回している企業がある • ノーコードツール自身はそれらの企業のビジネスはよく知らない • これはノーコードツールを使ってユーザー自身がビジネスロジックを記述しているような状態 • こうなると、ビジネスロジックに変更があってもドメイン層をいじる必要が全くない
なぜノーコードツールは安定しているのか? • 個別のビジネス的な要件が削ぎ落とされることからドメインモデルの安定性は生まれているのではない か? • ユーザー自身のドメインモデルの使い方で振る舞いを調整できるからじゃないか?
とはいえノーコードツールを目指せばいいわけではない • ノーコードツールは1企業からみると包含する範囲が広すぎる ◦ 抽象度が高すぎて必要な情報の欠落や必要以上の認知負荷上昇につながってしまう • 対象のドメインをちょうど包含できる抽象が良い抽象 ◦ 自社の要求の範囲で抽象化されたドメインモデルを目指していく必要がある
ノーコードツールの話をまとめると ... • 個別のビジネス要件をドメインモデルから追い出し抽象化することで安定性が高まる • しかし、何でも抽象化してしまうと抽象度が高くなりすぎて辛い
安定度の低いビジネスロジックだけド メインモデルから追い出せばいいので は?
どうやって追い出すのか?
共通性・可変性 • 対象となる物事の中で共通する部分としない部分 • 共通性は静的な構造 ◦ 可変性を受け入れる枠組み • 可変性は動的 •
詳しくはマルチパラダイムデザインという書籍で
お弁当で考えてみる • 共通性 ◦ 商品名と価格からなる データ構造 • 可変性 ◦ 具体的な商品名や価格と
いった状態
PHP で表現してみる • 共通性はクラスという静的な形 で表現 • 可変性は変数として表現
PHP で表現できる共通性・可変性(一部) デザインパターンなどは更に様々な共通性・可変性を表現できる ※実際には共通性・可変性の他にバインディング時期など他にも考慮するポイントがある 共通性 可変性 機能 振る舞い・データ構造 状態 Class
名前(意味) or 振る舞い 振る舞い or 実装 Interface 振る舞い 型 Trait データ構造 小さい値の組 Enum
要件を可変性で捉えて ビジネスロジックを抽象化してみる
申請アプリケーションの例 • スターフェスティバルはお弁当を販売する ECサイトを運営している • ECサイトに並ぶお弁当は外部の飲食店のものも含まれる • クオリティ担保のため、社内の審査を通過したお弁当だけを ECサイト上に並べている •
商品情報を審査をするためのアプリケーションを構築したい • 「3次審査までできるようにしてほしいです!」
3次審査という要件を 共通性で実装する例 3次審査以外のバリエーションを考慮し ないため、三次承認までのステータス を静的に表現する
3次審査という要件を 可変性で実装する例 2次審査までの申請など承認ステップ のバリエーションを仮定し、動的に表現 したバージョン
ドメインモデルに可変性を組み込む • 要件を可変性として捉えることで、ドメインモデルの抽象度が一段上がる • 可変性のスコープ内の変更要求であればドメインモデル自体の変更が不要になる • ドメイン層に変更を加えなくても変更要求に対応できる状態に少し近づいた?
YAGNI との付き合い方 • kawashima さんの素晴らしい資料に沿ってやっていくと良さそう ◦ 「それはYAGNIか? それとも思考停止か ?」 https://www.slideshare.net/kawasima/yagni
◦ 変更要求が発生したタイミングなどで変更の発生した部分を可変性に切り出していくといいのではないか • 何でも可変性にしていくと抽象度が高くなりすぎる可能性 • ユースケースの幅が広がりそうなところを可変性にすると面白いことになるかもしれない
可変性についてもっと知りたい人は • マルチパラダイムデザイン • データモデリングでドメインを駆動するという書籍で紹介されている ◦ テーブル駆動方式 ◦ DSL ◦
定義体方式
まとめ • 安定度の低いビジネスロジックをドメイン層に入れると、影響範囲が広くなりがちで辛いのではないか • 安定度を高めるためにはビジネスロジック自体の抽象度を上げていく必要があるのではないか • 要件を可変性で捉えることでドメインモデルの抽象度が上がっていくのではないか • ドメインモデルに可変性を組み込んでいくことで、変更要求をドメイン層の手前で吸収できることが増える のではないか
• そうなるとさいきょうのレイヤードアーキテクチャ感があるのではないか
We are hiring !!