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
1.1k
3
Share
独立したコアレイヤパターンをためしてみる / try independent core layer pattern
Fukuoka.php Vol.26 で発表した内容です
TAKAHASHI Kunihiko
August 08, 2018
More Decks by TAKAHASHI Kunihiko
See All by TAKAHASHI Kunihiko
Apache から LiteSpeed に乗り換えてみませんか? / php-conference-japan-2019-track5-hello-litespeed
kunit
1
1.7k
Webアプリケーションエンジニアだった私がホスティング事業に興味を持った理由 / Fukuoka UIJ Turn gmo pepabo
kunit
0
550
アプリケーションエンジニアな私がホスティング業界に来て感じたあれこれ / ChugokuDB Vol27
kunit
0
660
Google App Engine PHP 7.2 を試してみる #phpstudy / google app engine php 7.2
kunit
1
1k
CircleCI 2.0 を使い倒そう / phpcon kansai 2018 circlci docker
kunit
7
2.8k
PHPのバージョンアップについてあれこれ / luncers lunch study 3 php version up
kunit
0
2.3k
CircleCI の歩き方 / CircleCI #phpstudy
kunit
2
280
CircleCI 2.0 をつかってみよう / CircleCI #phpcondo2017
kunit
0
750
Docker for Mac/Winってどうなの? / #fukuokaphp docker for mac and win
kunit
0
280
Other Decks in Technology
See All in Technology
古今東西SRE
okaru
2
180
Agent Skillsで実現する記憶領域の運用とその後
yamadashy
2
1.7k
「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata
nihonbuson
PRO
5
1k
Agent の「自由」と「安全」〜未来に向けて今できること〜
katayan
0
350
AI駆動開発で生産性を追いかけたら、行き着いたのは品質とシフトレフトだった
littlehands
0
490
会社説明資料|株式会社ギークプラス ソフトウェア事業部
geekplus_tech
0
220
雑談は、センサーだった
bitkey
PRO
2
230
セキュリティ対策、何からはじめる? CloudNative環境の脅威モデリングと リスク評価実践入門 #cloudnativekaigi
varu3
5
770
ESP32 IoTを動かしながらメモリ使用量を観測してみた話
zozotech
PRO
0
110
大学職員のための生成AI最前線 :最前線を、AIガバナンスとして読み直すためのTips
gmoriki
2
4k
新卒エンジニア研修、ハンズオンの設計における課題と実践知/ #tachikawaany
nishiuma
2
140
AIが盛んな時代に 技術記事を書き始めて起きた私の中での小さな変化
peintangos
0
370
Featured
See All Featured
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
55k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
920
GitHub's CSS Performance
jonrohan
1032
470k
How to Think Like a Performance Engineer
csswizardry
28
2.6k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
320
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
5.8k
Optimizing for Happiness
mojombo
378
71k
Technical Leadership for Architectural Decision Making
baasie
3
360
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
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と前までは かを深く理解した人にく理解するためには前した人にも、本当の意味で救 これから学ぶソフトウェアぼ同じ思想のアーうと前までは している人にも対 応するロジックをでき換えたのか?る柔軟なパターンだとなパターンだと前までは 思っていたよりもう ✔
つかってみると前までは もっと前までは こうすべき換えたのか? と前までは かど経過しんど経過しんでてき換えたのか?そうな気がするがフレームワークする のバージョンアッで、本当の意味で救もっと前までは 深く理解した人に堀していきたいとしていき換えたのか?たいと前までは 思っていたよりも う
ご清聴清聴 あり所属がフレームワークと前までは う ご清聴ざいました