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
独立したコアレイヤパターンをためしてみる / try independent core lay...
Search
TAKAHASHI Kunihiko
August 08, 2018
Technology
3
930
独立したコアレイヤパターンをためしてみる / try independent core layer pattern
Fukuoka.php Vol.26 で発表した内容です
TAKAHASHI Kunihiko
August 08, 2018
Tweet
Share
More Decks by TAKAHASHI Kunihiko
See All by TAKAHASHI Kunihiko
Apache から LiteSpeed に乗り換えてみませんか? / php-conference-japan-2019-track5-hello-litespeed
kunit
1
1.5k
Webアプリケーションエンジニアだった私がホスティング事業に興味を持った理由 / Fukuoka UIJ Turn gmo pepabo
kunit
0
460
アプリケーションエンジニアな私がホスティング業界に来て感じたあれこれ / ChugokuDB Vol27
kunit
0
560
Google App Engine PHP 7.2 を試してみる #phpstudy / google app engine php 7.2
kunit
1
920
CircleCI 2.0 を使い倒そう / phpcon kansai 2018 circlci docker
kunit
7
2.6k
PHPのバージョンアップについてあれこれ / luncers lunch study 3 php version up
kunit
0
2.1k
CircleCI の歩き方 / CircleCI #phpstudy
kunit
2
250
CircleCI 2.0 をつかってみよう / CircleCI #phpcondo2017
kunit
0
670
Docker for Mac/Winってどうなの? / #fukuokaphp docker for mac and win
kunit
0
200
Other Decks in Technology
See All in Technology
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
終了の危機にあった15年続くWebサービスを全力で存続させる - phpcon2024
yositosi
17
16k
[Ruby] Develop a Morse Code Learning Gem & Beep from Strings
oguressive
1
170
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
600
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
230
フロントエンド設計にモブ設計を導入してみた / 20241212_cloudsign_TechFrontMeetup
bengo4com
0
1.9k
多領域インシデントマネジメントへの挑戦:ハードウェアとソフトウェアの融合が生む課題/Challenge to multidisciplinary incident management: Issues created by the fusion of hardware and software
bitkey
PRO
2
110
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
150
Snykで始めるセキュリティ担当者とSREと開発者が楽になる脆弱性対応 / Getting started with Snyk Vulnerability Response
yamaguchitk333
2
190
kargoの魅力について伝える
magisystem0408
0
210
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
560
DevFest 2024 Incheon / Songdo - Compose UI 조합 심화
wisemuji
0
120
Featured
See All Featured
Music & Morning Musume
bryan
46
6.2k
Typedesign – Prime Four
hannesfritz
40
2.4k
Being A Developer After 40
akosma
87
590k
Done Done
chrislema
181
16k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Docker and Python
trallard
42
3.1k
4 Signs Your Business is Dying
shpigford
181
21k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Designing Experiences People Love
moore
138
23k
A Philosophy of Restraint
colly
203
16k
Navigating Team Friction
lara
183
15k
Transcript
独立したした コアレイヤパターン をためしてみる Fukuoka.php Vol.26 2018-08-08 @kunit
自己紹介 ✔ @kunit ✔ 合同会社ねこもり所属ねこもり所属所属 ✔ ちょっと前までは 前までは までは PHP/フ
レームワークのバージョンアのバージョンアッバージョンアッ プのお手伝いとかのバージョンアッお手伝いとかして手伝いとかしてましいと前までは かしてました
もうそんなにたつんですね(遠い目い目 ✔ PHPerがフレームワークフレームワークのバージョンアを使うう ようになってから15年ほど経過しほど経過し経過しし た ✔ フレームワークのバージョンアを使うっていな かった頃に比べればいろに比べればいろいろべればいろいろと前までは 改 善されたされた
✔ だがフレームワーク、本当の意味で救本当の意味で救われのバージョンアッ意味で救われたので救われたのわれたのバージョンアッ か?
フレームワークのバージョンアのバージョンアッバージョンアップのお手伝いとか ✔ そのバージョンアッ15年ほど経過しのバージョンアッ間に、あなたはいに、本当の意味で救あなたはいくつ フレームワークのバージョンアをのバージョンアッり所属かえたのバージョンアッか? ✔ 使うっていたフレームワークのバージョンア(のバージョンアッ バージョン)はど経過しれくらいのバージョンアッ期間に、あなたはい、本当の意味で救 安定してつかえたのしてつかえたのバージョンアッか? ✔ フレームワークのバージョンアのバージョンアッバージョンアッ
プのお手伝いとかのバージョンアッ追従をするためにどをするためにど経過しれくらい コードを書き換えたのを書き換えたのか?き換えたのか?換えたのか?えたのバージョンアッか?
アプのお手伝いとかリケーションのバージョンアッ寿命 ✔ 我々が思っていたよがフレームワーク思っていたよりもっていたより所属も長いい ✔ 5年ほど経過し、本当の意味で救10年ほど経過し稼働し続けているし続けているけている ものバージョンアッがフレームワークたくさんある ✔ フレームワークのバージョンア(のバージョンアッバージョ ン)のバージョンアッ寿命はアプのお手伝いとかリケーション より所属も遥かに短いかに短いい
何かがおかしいかがフレームワークお手伝いとかしてかしい ✔ アプのお手伝いとかリケーション本来のコーのバージョンアッコー ドを書き換えたのに集中するためにフレするためにフレーム ワークのバージョンアを採用したのではなかしたのバージョンアッではなかっ たのバージョンアッか? ✔ 我々が思っていたよはフレームワークのバージョンアに依存 しすぎているのバージョンアッではないか?
独立したしたコアレイヤパターン ✔ しんばらさんがフレームワーク提案されていされてい るアプのお手伝いとかリケーション実装パターパター ン ✔ PHPのバージョンアッ現場でちらっと話がでちらっと前までは 話がでがフレームワークで ている ✔
PHPCon関西 非公式前までは 夜祭 で発表
簡略化されているがされているがフレームワーク ✔ 既存のバージョンアッアーキテクのバージョンアチャやパターやパターパター ンをもと前までは にしていて、本当の意味で救それより所属も かなり所属簡略化されているがされていてわかり所属やパター すい ✔ と前までは はいえ、本当の意味で救理解するためには前するためには前までは
提知識がそこそこ必要がフレームワークそこそこ必要 ✔ と前までは いうこと前までは で、本当の意味で救今日はその前提はそのバージョンアッ前までは 提 知識がそこそこ必要をちらっと前までは 紹介する
レイヤードを書き換えたのアーキテクのバージョンアチャやパター(1)
レイヤードを書き換えたのアーキテクのバージョンアチャやパター(2) ✔ レイヤードを書き換えたのアーキテクのバージョンアチャやパターは 下の層に向かってのバージョンアッ層に向かって依存に向かって依存してかって依存していく ✔ 最終的な依存先がインな依存先がインフラ層がフレームワークインフラ層層に向かって依存 と前までは いうのバージョンアッはお手伝いとかしてかしいのバージョンアッではない か? ✔
私達が集中したいのがフレームワーク集中するためにフレしたいのバージョンアッはドを書き換えたのメイ ンロジックのバージョンアだったはずだ
ヘキサゴナルアーキテクのバージョンアチャやパター(1)
ヘキサゴナルアーキテクのバージョンアチャやパター(2) ✔ Ports and Adapters アーキ テクのバージョンアチャやパターと前までは も呼ばれるばれる ✔ 外側から中側に向かから中するためにフレ側から中側に向かに向かって依存してかって依存す
る ✔ 中するためにフレ側から中側に向かのバージョンアッ層に向かって依存がフレームワーク外に向かって依存してかってポート (インターフェース)を提供し、外を提供し、外し、本当の意味で救外 側から中側に向かのバージョンアッ層に向かって依存はそのバージョンアッポートに従をするためにどったアダ プのお手伝いとかタを実装パターする
クのバージョンアリーンアーキテクのバージョンアチャやパター(1)
クのバージョンアリーンアーキテクのバージョンアチャやパター(2) ✔ ヘキサゴナルアーキテクのバージョンアチャやパターと前までは ほぼ同じ思想のアー同じ思想のアーキテ思っていたよりも想のアーキテクチのバージョンアッアーキテクのバージョンアチャやパター ✔ 外側から中側に向かから内側から中側に向かへ依存する依存する ✔ ど経過しちらも一番内部のドメインロのバージョンアッドを書き換えたのメインロ ジックのバージョンアがフレームワーク最上位の層と位置づけのバージョンアッ層に向かって依存と前までは 位の層と位置づけ置づけるづける
✔ 円形の図、わかりづのバージョンアッ図、本当の意味で救わかり所属づらくないで すか?
クのバージョンアリーンアーキテクのバージョンアチャやパター(3) ✔ 円錐のほうがいい気のバージョンアッほうがフレームワークいい気がするがフレームワークする ✔ 内部のドメインロと前までは 言うよりも上位うより所属も上位の層と位置づけ
クのバージョンアリーンアーキテクのバージョンアチャやパター(4) ✔ 最近いい本がでたのいい本がフレームワークでたのバージョンアッ でお手伝いとかしてすすめ! ✔ Clean Architecture 達が集中したいの人 に学ぶソフトウェアぶソフトウェアのソフトウェアのバージョンアッ 構造と設計と前までは
設計 ✔ 角さんと髙木さんさんと前までは 髙木さんにさんに よる読みやすい翻訳!みやパターすい翻訳!
CQRS(1) ✔ Command and Query Responsibility Segregation ✔ コマンドを書き換えたのクのバージョンアエリ責務分離 ✔
元になったのは になったのバージョンアッは Bertrand Meyer のバージョンアッオブジェクのバージョンアト指向かって依存して入 門の中の のバージョンアッ中するためにフレのバージョンアッ CQS
CQS ✔ "あらゆるメソッドを書き換えたのは、本当の意味で救何かがおかしいらか のバージョンアッアクのバージョンアションを実行する「コマする「コマコマ ンドを書き換えたの」あるいは呼ばれるび出し元に出し元にし元になったのは に データを戻す「クエリ」のす「コマクのバージョンアエリ」のバージョンアッいず れか一方でなければならでなければならず、本当の意味で救両 方でなければならのバージョンアッ機能を兼ね備えてはを兼ね備えてはいけね備えてはいけなえてはいけな い。
つまり所属、本当の意味で救何かがおかしいかのバージョンアッ質問をすることで、をすること前までは で、本当の意味で救そのバージョンアッ質問をすることで、へ依存するのバージョンアッ答えが変えがフレームワーク変 わってしまってはいけない。もう少しきちんと言うしき換えたのか?ちんと前までは 言うよりも上位うと前までは 、本当の意味で救メソッドを書き換えたのがフレームワーク値をを 戻す「クエリ」のすのバージョンアッは、本当の意味で救そのバージョンアッメソッドを書き換えたのがフレームワーク参照透過し性を持ち、何も副を持ち、何も副作用ち、本当の意味で救何かがおかしいも副作用したのではなかを及ぼさないぼ同じ思想のアーさない 場でちらっと話が合だけでなければいけない"
CQRS(2) ✔ 副作用したのではなかがフレームワーク伴う処理は「コマう処理は「コマコマン ドを書き換えたの」、本当の意味で救副作用したのではなかがフレームワーク伴う処理は「コマわない処理は 「コマクのバージョンアエリ」と前までは してそれぞれ別ののバージョンアッ メソッドを書き換えたのから発行する「コマさせる
材料は揃ったは揃ったった ✔ 独立したしたコアレイヤパターンを 説明するための材料するためのバージョンアッ材料は揃ったはそろった ✔ ヘキサゴナルアーキテクのバージョンアチャやパター等 より所属もさらにレイヤのバージョンアッ数を簡素化を簡素化されているが したアプのお手伝いとかリケーション実装パターパター ンと前までは いうこと前までは
になる ✔ サービスレイヤと前までは コアレイヤー のバージョンアッ2層に向かって依存しかない
コアレイヤ ✔ 本来のコーアプのお手伝いとかリケーションがフレームワーク解するためには前決すべすべ き換えたのか?問をすることで、題に対応するロジに対応するロジックをするロジックのバージョンアを記述すす る(フレームワークフレームワークのバージョンアからは隔離) ✔ ユースケース、本当の意味で救ドを書き換えたのメインモデル ✔ 内部のドメインロのバージョンアッ層に向かって依存であり所属、本当の意味で救一番上位の層と位置づけのバージョンアッ層に向かって依存 ✔
外部のドメインロのバージョンアッ層に向かって依存であるサービスレイヤか らアクのバージョンアセスされると前までは き換えたのか?に利用したのではなかしても らうポート(インタフェース)を提供し、外
サービスレイヤ ✔ コアレイヤと前までは フレームワークのバージョンアと前までは のバージョンアッ 受け渡しを行うもけ渡しを行うものしを行する「コマうものバージョンアッ ✔ コアレイヤから提供し、外されたポート に対するアダプのお手伝いとかタを実装パターする ✔
フレームワークのバージョンアのバージョンアッ仕様が変わるとがフレームワーク変わると前までは 影響を受けるを受け渡しを行うもける ✔ フレームワークのバージョンア等のバージョンアッ独自のバージョンアッロジッ クのバージョンアはアダプのお手伝いとかタに閉じ込めるじ思想のアーキテ込めるめる
ポート/アダプのお手伝いとかタ ✔ 副作用したのではなかがフレームワークあるものバージョンアッは Command ポート、本当の意味で救副作用したのではなかがフレームワークない値をを返却するだするだ けのバージョンアッものバージョンアッは Query ポートと前までは してコア レイヤで定してつかえたの義するする
✔ そのバージョンアッ他トランザクショトラ層ンザクのバージョンアションを制御する する Transaction ポートも合わせて定してつかえたの義する する ✔ しんばらさんがフレームワーク例で定義しているで定してつかえたの義するしているのバージョンアッは このバージョンアッ3つのバージョンアッみ
連携の流れのバージョンアッ流れれ ✔ コアレイヤでポート(フレームワークインタ フェース)を提供し、外を定してつかえたの義する ✔ コアレイヤはポートにのバージョンアッみ依存 ✔ サービスレイヤではポートに対 してアダプのお手伝いとかタを実装パター ✔
サービスレイヤがフレームワークコアレイヤに 依存している形の図、わかりづと前までは なる
デモ ✔ しんばらさんがフレームワーク準備えてはいけなされたも のバージョンアッを少しきちんと言うしだけ変更したものをしたものバージョンアッを 作ってき換えたのか?たのバージョンアッでそれをデモしま す
フレームワークのバージョンア依存からのバージョンアッ脱却するだ ✔ 同じ思想のアーキテユースケースをLaravel、本当の意味で救 CakePHP2、本当の意味で救 CakePHP3 から使う えている ✔ ユースケースと前までは いうドを書き換えたのメインロジッ
クのバージョンアを維持ち、何も副作用したままフレームワークのバージョンアを変 えること前までは がフレームワークでき換えたのか?る ✔ フレームワークのバージョンアを変えなくても、本当の意味で救将 来のコーのバージョンアッバージョンアップのお手伝いとかに対して強い機い機 構をつくること前までは がフレームワークでき換えたのか?たと前までは いえる
CakePHP2ユーザのバージョンアッ悩みみ ✔ 国内で爆発的な依存先がインに流れ行する「コマった CakePHP2 のバージョンアッアプのお手伝いとかリケーションを ど経過しうするのバージョンアッかと前までは いう悩みみをお手伝いとかしてそらく たくさんのバージョンアッ人がフレームワーク持ち、何も副作用っている ✔ それのバージョンアッ一つのバージョンアッ戦略と前までは
して、本当の意味で救ドを書き換えたのメイ ンロジックのバージョンアをユースケースに切り出り所属出し元に し、本当の意味で救データベースアクのバージョンアセスをいち早 く CakePHP3 のバージョンアッ ORM をつかう と前までは いう戦略はど経過しうだろうか?
CakePHPのバージョンアッバージョンアップのお手伝いとか ✔ CakePHP4がフレームワーク見えてきたえてき換えたのか?た 今、本当の意味で救CakePHP2からのバージョンアッ移行する「コマのバージョンアッ一つのバージョンアッ選 択肢としてありえると前までは してあり所属える気がするがフレームワークしている ✔ なお手伝いとかして、本当の意味で救このバージョンアッ案されていはPHPCon関西でいろい ろ議論していた時に、していた時に、はらださんに、本当の意味で救はらださんから出し元に た案されてい
✔ 一番変化されているがのバージョンアッ大きい き換えたのか?い ORM 部のドメインロ分から変え てしまうと前までは いう大きい 胆な案だったが、な案されていだったがフレームワーク、本当の意味で救コア レイヤパターンを組み合わせることみ合わせること前までは によ り所属現実的な依存先がインな気がするがフレームワークしてき換えたのか?た
いろいろ試していきましょしていき換えたのか?ましょう ✔ 独立したしたコアレイヤパターンは、本当の意味で救 DDDと前までは かを深く理解した人にく理解するためには前した人にも、本当の意味で救 これから学ぶソフトウェアぼ同じ思想のアーうと前までは している人にも対 応するロジックをでき換えたのか?る柔軟なパターンだとなパターンだと前までは 思っていたよりもう ✔
つかってみると前までは もっと前までは こうすべき換えたのか? と前までは かど経過しんど経過しんでてき換えたのか?そうな気がするがフレームワークする のバージョンアッで、本当の意味で救もっと前までは 深く理解した人に堀していきたいとしていき換えたのか?たいと前までは 思っていたよりも う
ご清聴清聴 あり所属がフレームワークと前までは う ご清聴ざいました