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.4k
Webアプリケーションエンジニアだった私がホスティング事業に興味を持った理由 / Fukuoka UIJ Turn gmo pepabo
kunit
0
450
アプリケーションエンジニアな私がホスティング業界に来て感じたあれこれ / ChugokuDB Vol27
kunit
0
550
Google App Engine PHP 7.2 を試してみる #phpstudy / google app engine php 7.2
kunit
1
910
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
660
Docker for Mac/Winってどうなの? / #fukuokaphp docker for mac and win
kunit
0
190
Other Decks in Technology
See All in Technology
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
140
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
250
Can We Measure Developer Productivity?
ewolff
1
150
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
130
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.5k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Done Done
chrislema
181
16k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Designing for Performance
lara
604
68k
Automating Front-end Workflow
addyosmani
1366
200k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
900
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Code Reviewing Like a Champion
maltzj
520
39k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
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と前までは かを深く理解した人にく理解するためには前した人にも、本当の意味で救 これから学ぶソフトウェアぼ同じ思想のアーうと前までは している人にも対 応するロジックをでき換えたのか?る柔軟なパターンだとなパターンだと前までは 思っていたよりもう ✔
つかってみると前までは もっと前までは こうすべき換えたのか? と前までは かど経過しんど経過しんでてき換えたのか?そうな気がするがフレームワークする のバージョンアッで、本当の意味で救もっと前までは 深く理解した人に堀していきたいとしていき換えたのか?たいと前までは 思っていたよりも う
ご清聴清聴 あり所属がフレームワークと前までは う ご清聴ざいました