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
930
さいきょうのレイヤードアーキテクチャについて考えてみた
吉祥寺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
1
770
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
10
2.2k
フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
yahiru
16
13k
ゆるふわCQRS入門
yahiru
2
660
設計におけるソリューションドメイン
yahiru
3
1.7k
PHPで始めるGitHub Actions
yahiru
1
770
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
Gleamという選択肢
comamoca
6
760
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
1.1k
FormFlow - Build Stunning Multistep Forms
yceruto
1
190
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
860
関数型まつりレポート for JuliaTokai #22
antimon2
0
160
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
330
エラーって何種類あるの?
kajitack
5
310
PicoRuby on Rails
makicamel
2
100
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
47
31k
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
1
690
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
150
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
100
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
GraphQLとの向き合い方2022年版
quramy
48
14k
Code Review Best Practice
trishagee
68
18k
Side Projects
sachag
455
42k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Become a Pro
speakerdeck
PRO
28
5.4k
Bash Introduction
62gerente
614
210k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
930
Optimising Largest Contentful Paint
csswizardry
37
3.3k
A Modern Web Designer's Workflow
chriscoyier
694
190k
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 !!