この番組はエンジニアの成長は楽しい学びからおもとに日々インプットした話題をワイワイお届けするラジオになってますというわけで順平新年新年じゃないや順平フィリピン一発目の収録でございますついに

気になりすぎるからさ最初の1,2分ぐらいでフィリピン生活最初の数日どう?っていう気がしてまずフィリピンインして一人部屋なんで結構ストレスフリーでやらせていただいてて英語に関しては1日中英語浴びまくってるんで英語を伸ばすにはっていう答えがもうすでに見えていて僕は

もう留学環境を変えるしかないなっていう結論にすでに至ってるぐらいにはいますつまり今の道は正解だと正解ですね最速なのかなと思いますねちょっと四苦八苦しながら一応やってますけどなんとかついていけてるのかなそんな気がしてます素晴らしい僕のお気に入りの先生が何人かいるんですが

南アフリカ共和国の先生が女性の先生でメデューサみたいな先生がいてユニークな人なんでいつかちょっと紹介しますねゲストで英語イングリッシュポッドキャストイングリッシュポッドキャストまあまあいろんな人がいますね楽しいです元気にやっておりますそいつは何よりだ何食べた何食べたフィリピン料理食べた

食べてないかいなんかシシグシシグだっけシシグ食べてないかもしれないえーとあの基本毎日ビュッフェなんですよバイキングみたいな感じであーはいはいでそれで結構あの日本人韓国人向け学校みたいな感じだったりするんで日本食あとコリアン料理うんであとはなんかそれ以外がちょっと基本よくわからないのでその中にもしかしたらフィリピン料理が混じっているかもしれないあー

土日で屋台歩き回ってもらうしかないですねいや俺お腹下すの怖いですよねまあでも経験として今だけで下せるのなんてまあまあまあ下しとけ下しとけそんなもんねまあ今回は短編ですけどいつかちょっとまとまったらねガッツリ教えてって感じではいというのでお便り会ですきましたというのでお便り読みますはいはい

ラジオネームもしもさんからのお便りですありがとうございますポッドキャストで話してほしいこといつも楽しく聞かせてもらっています朝夜の通勤時間にいつも聞かせてもらっていて日々モチベをもらっていますありがとうございますありがとうございます私は最近アーキテクチャやソースコードが整頓されていないアプリ開発の現場にテックリードで参画しておりアプリケーションを改善する義務が

アプリケーションを改善する責務がありますその中でクリーンアーキテクチャにてアーキテクチャを再構築しようとしておりクリーンアーキテクチャの基礎他の現場ではどのようにクリーンアーキテクチャを実現しているのかなどなどのお話を聞きたいですというので

お便りいただいていますありがとうございます僕らもいつもモシモさんからモチベーションをもらっております本当にそうです今日ももらっていますお便りありがとうございますありがとうございますというので2個ですねクリーンアーキテクチャの基礎とあとはクリーンアーキテクチャを実現しているのをするにはどういう風にやってるのみたいなところになるのかなと思ってますはい

どっから話しましょうかクリーンアーキテクチャとはみたいなところからクリーンアーキテクチャっていうキーワード危険ですからね危険なんですか危険ワードじゃないですかこれ人によってさ解釈がずれてさ噛み合ってないワード

として結構名高いイメージあるんだよなまあ確かにそれはあるかもフィリピン行く前にクリーンアーキテクチャの本を僕積んでて持ってったってこと?いや結局入りきらなくて持ってきなかったんですけど積んでてしかも中身も結果読めてないっていうのでクリーンアーキテクチャっていうのはあの本のことなんじゃないかと思ったりもしています

危険ですか別にあってはいるよねあの本の名前クリーンアーキテクチャですもんね別にそんな分厚い本じゃなかったよねでもそこそこクリーンコードに比べればだよねクリーンコードの半分ぐらいじゃなかったそうだったんですね他のねボボウジ3本に比べたらまあ中の下ぐらいですかいやボボウジ3本結構あののきなみ薄いっすよあれそうじゃっけうんうん

ノキノミアジアイルとかは薄かったなって記憶があるんですけどそんなこと置いといてクリーンアーキテクチャーちょっとこれいろいろ意見があるところで非常に怖いなと思いながらお話しするんですけど僕の個人的な考え方ではクリーンアーキテクチャーっていう本に書かれているクリーンアーキテクチャーは

なんていうんだろうなこのアーキテクチャーをクリーンアーキテクチャーと呼びますというよりはですねこういうアーキテクチャーがクリーンなアーキテクチャーなんだよと言っていると解釈していますそうですね特定のアーキテクチャーパターンを指すというよりはクリーンなアーキテクチャーってこういう共通点あるよねボンだよねあれそうそうそうそうで

こういう共通点あるよねっていうところで言うとざっくりアーキテクチャがまず層になってますとこれ層って言うとレイヤードアーキテクチャっぽくなるんですけど一旦忘れてもらって層になっていて真ん中にエンティティドメインみたいなデータの

定義というか本体というかみたいなのがあってその外側にユースケーシーズってクリーンアーキテクチャの図には書いてますけどそのドメインを操作する層ですねがあってさらに外側にいわゆるコントローラーとかコントローラーは外部とのやり取りをする部分っていうんですかねうんうんうん

フレームワークとかだったらHTTPとソフトウェアの間に挟まってる部分みたいなそんな感じのイメージですかねそうですねでまたそのさらに外側にDBみたいなそういうインクラストラクチャー層みたいなやつとかUIとかがありますよというざっくりクリーンアーキテクチャになりますクリーンアーキテクチャって調べると真っ先に出てくる

丸い玉ねぎみたいな図みたいなまたややこしい言い方しますね丸い玉ねぎそうね丸くない玉ねぎあるのかな丸くない玉ねぎはわかんないですね四角いスイカもあるんで四角いスイカもあるからななのであとなんか層になってて依存の向きが必ず外から内になってますうんうんうん合ってるよな合ってるよはい

その逆は存在しませんそうなっていると保守性が高いどこか変えようと思っても影響範囲が最小になってなおかつ各レイヤーの中の例えばコントローラーだったらコントローラーだけで単一責務になっていてそういう構造にできますよというのがクリーンアーキテクチャと呼ばれるアーキテクチャになりますこのぐらいの説明でいいんですかね

そうですね一応ビジネスロジックを一番中心に置いてるイメージがあってエンティティとかそういうのってその理由だけど多分ビジネスモデルが一番変わりにくいからそこに依存させておくことによって変更とかに対して安全な作りになりやすいよねっていう解釈でいますそれって本か何かに書いてました?それともノリさんなりの解釈ですか?いや何かに書いてあったよ

それはちょっと目から鱗ちょっとこういう系のやつ読みすぎて情報源忘れましたでもすごいそれっぽいですねビジネスモデルが変わったら別にアプリ違うのでいいやんって話ですからねだからこそそういうモデルを一番中心に置いておいて他に依存しないようにしておくとそうすれば別にアプリケーションの見た目変わることでビジネスロジックを変える必要はないと

でもビジネスロジック変わったらそれはアプリケーションの見た目も変わっていくよねだからそこはしょうがないよねみたいなイメージですねあと例えばDBもそうなんですけどストレージとかストレージサービスとかあとは外部の連携システムとかそういうアプリケーションの外側にあるものも置き換わりやすいじゃないですかDBのエンジン変えようみたいなマイスキルからポスクにしようみたいな

はたまたノエスケール使ってみようぜとかそういうのもアプリケーションのライフサイクル的に変更しやすいようにクリーンアーキテクチャでは一番外側の層に置かれているとだからノリさんがさっき言ってたようにざっくり変更しやすい順に外から並んでいるような作りになっているんですよねこういうのがクリーンアーキテクチャと呼ばれるものなんですけどこれはちょっと

お便りに回答する上でクリーンアーキテクチャをどう実現するかっていうところでクリーンアーキテクチャで作るという方法でクリーンアーキテクチャを実現することはないと思ってますなのでクリーンアーキテクチャというアーキテクチャはないと思ってるんで世の中一般的に試験なんですけどクリーンアーキテクチャでやってますっていうのってオニオンアーキテクチャなんじゃないかなと思ってますうん

データあんまり覚えてないんですがなんか確かに言ったことある気がするですねクリーンアーキテクチャー話した時に本当出てきてますねすいません忘れたのでもう一度いいですかオニオンアーキテクチャーはですね丸い玉ねぎみたいなアーキテクチャーです丸い玉ねぎみたいなアーキテクチャーでさっきクリーンアーキテクチャーの説明したんですけどそれにすごい似てます

で一番真ん中超中心玉ねぎでいう丸っこいところ急根?あれ全体で急根か玉ねぎのコアこれドメインモデルっていうやつになりますねでまあこれはドメインモデルというものでノリさんがさっき言ったようなビジネスのコアになりますでそのドメインモデルっていうのが中心にあってエンティティとか定義されてるところですねうんうんうん

そこからさらに外側にドメインサービスっていうのがありますこれはドメインモデルで定義されたものを操作して何がをやる部分になりますビジネスに関するロジックとかを処理します今二重になってるんですけどそのさらに外側にアプリケーションサービスというものがありますこれはドメインモデルドメインサービスのさらに外側にあって

そのドメインサービスを呼び出しながら 複数のドメインモデルというかドメインサービスにまたがって何かの操作をするようなものが書かれるんですけどユースケースとかがここに当たるんですかねユースケースはそこに当たる気がしますアプリケーションサービスというのがありますこれがあの

アプリケーションサービスというのがあってさらにその外側にこれ一番外側ですねさっきクリーンアーキテクチャで言ったようなインフラストラクチャTVとかストレージサービスとか外部APIとかあとはUIあとテストもここに含まれるんですねこのテストって多分あんまり詳しくないんですけど内結ですよね多分ね

単体テストではないっていう感じで真ん中からドメインモデルドメインサービスアプリケーションサービス外側が同じ層でUIインフラストラクチャーテストテストってそこにあるんだねなんかもう別次元の存在なのかと思ってたわ玉ねぎに一本串刺したみたいな状態なのかと思ってた単体テストとかひっくるめるとねそうなると思います通オニオンアーキテクチャがあってただまああの

こんなこと言ったら怒られるかもしれないですけど考え方は一緒だと思いますスクリーンアーキテクチャと結局変わりにくい場所に依存させていけよっていう原則よねそうですね実際作ってみた時もそこまで変わんないんじゃないかなと思いますねそのレイヤーの分けは名前は違うんですけどこんなこと言ったら怒られるかもしれないですけどね

何とだ?違うんじゃないかなクリーンアーキテクチャーの名前を使ってアーキテクチャーを作ってみた場合とオニオンアーキテクチャーアーキテクチャーを組んでみた場合変わるのは命名ぐらいでは本質的な役割はそんな変わってないんじゃないかみたいなはいそうですこんなこと言ったら怒られるかもしれないですけどでもね私も結構そっち寄りの考えですね

考え方は似てると思うんでというのでオニオンアーキテクチャを実現しようと思ったら現場でどういうことをやっていくべきかっていう話に移っていこうかなと思いますここでいきなりのりさんに振りますのりさんに振りますかこれね僕思うにコードに関する戦略だけじゃ足りないと思うんですよねこれを推進するってなった時になんかこのこういうクリーンアーキテクチャみたいな原理原則とかってさ

人によって知ってる知らないあるじゃないですかありますねってなった時に知らない人から見たらこれめっちゃ分かりにくい行動になると思っててそうですねこのディレクトリ役割なんすかみたいな問題が起きたりとかあとここにこれっぽい処理を置くんだねみたいななんか表面のところだけ理解した上で書くとその後どんどんちょっとずつちぐはぐなものが生まれて

結局中途半端クリーンアーキテクチャになるというか綺麗にレイヤー分かれなそうですよね知らない人ってなったら多分いきなり最初にアーキテクチャパターンこれです!ドコーンって示すのはあんまり良くないんじゃないかなちょっとレベル感にもよるんですけど集まってるチームの

今やってないなら大概わかんないですよねそうなのよ必ずしも成功しないなと思っててしかもコードレビューするときにさこういうアーキテクチャみたいなのを勉強して勉強した上でこう書くといいんだってなってただそれが誤った解釈をしてたりとか本質理解してないものだったときに出されるコードレビューを否定するのすごい辛いんですよここってこう…

こうしちゃったみたいなでももう直せない量がそうなってるみたいなっていうことも全然起きると思うんで僕はまずちっちゃいところから始めていく必要があるかなと思っていますでじゃあ一番ちっちゃいところってなんだろうっていう時に僕は多分まずはコードレビューなんじゃないかなって気がするんですよねほうコードレビューで

まずとにかくクリーンアーキテクチャとか原則みたいなところをある程度把握してる人が積極的にレビューに入るとここって将来こう変更した時にこういう問題が起きそうだよねみたいなところのじゃあアーキテクチャ的にこうやっていくといいよっていうちっちゃいコードレビューをまず積み重ねていった方がいい気がするんですよそれをやるとまずあんまり大規模な全体のアーキテクチャが変わるわけじゃないんですけど

細かいコードが綺麗になっていく気がする細かいコードが綺麗になっていったら次何するべきだろうなちょっと大規模な移行みたいなやつを1機能でやってみるとその1機能を少しずつ広げていって全体をクリーンにしていくみたいな動き方をしないといけないんじゃないかなっていう気がしているうんうん

つまりちっちゃく始めて知らない人たちの教育をしつつ大きくしていこうっていうそうだねコードレビューで教育しつつ土台が整ったなってタイミングで一機能をガッツってやってみるみたいなそれを参考にして他の人も実装してもらっていくみたいな感じの引っ張り方をするんじゃないかな質問いいですかはい

ノリさんの進め方めっちゃいいなと思いつつ難しいポイントもいろいろあると思うんですけど例えば1機能だけで別のアーキテクチャ例えばオニオンアーキテクチャ的にやろうと思った時にもともともともともと例えばインフラストラクチャ層が適切に分離してないようなアプリケーションだった場合一時的にDBにアクセスするコードが二重に存在し得る

可能性もあるじゃないですかあると思うその辺ってどういう風に進めていくイメージなんですかちょっとこれね僕まさに今似たようなことやってるんですよ自分で作ってるやつでこうやったらいいんじゃないかなって今うっすら思ってるのはもう回収済みのディレクトリを作っていくうんうんうんでそれ移行期間中はどうしようもない

両方ある過渡期だから過渡期は両方ある状態が存在するしなんなら存在してないと危ないんじゃないかなとすら思っている丸ごと置き換えは大変すぎるでしょっていう今回僕がやってるやつだと何をしたかったかっていうと今めっちゃ技術的なレイヤードアーキテクチャになってるんですよ技術的なレイヤードアーキテクチャはいそれこそザ

ルビーオンレールズとかザララベルみたいな感じなんですけどコントローラーっていうディレクトリにコントローラーバーって入っててモデルってとこにモデルボーンって入っててサービスってとこにサービスバーンって入っててみたいなそういう感じ技術的な関心ごとに基づいてパッケージ分けしているサブディレクトリも中にアクターが分かれてるくらい

これビジター用の機能だよねとかこれアドビン用の機能だよねみたいなっていうレベルでしか切ってないから大変なことになってるんですよ今ファイル数がいっぱいなんですね機能がいっぱいなんですねそもそもこれをどうにかしないといけないなと思ってあのー

今参考にしてるのはDDDで紹介されてるアーキテクチャのパターンみたいなとこなんですけどとにかくコンテキストちゃんと切ってそのコンテキスト内でパッケージ化していくみたいなのを進めたいって思ってるんですよなんでもうこれから新しく実装する機能とかあとこれから回収する機能

に関してはそのコンテキストの中にじゃあ今回だったらユーザー登録に関するコンテキストみたいなやつで切っちゃってその中にどんどん移行していって使わなくなったファイル消していってっていうことをやっていってますねだからそのコンテキストっていうディレクトリに入ってるやつは新しくなった部分古い部分は使わなくなったものから消していくっていう感じでやってますね

なるほどでもこれね混在期間中きついよまあでもそれはどうやってもそうなるんじゃないかなどうなんでしょうね一番最悪なのはこれやってる最中にいやこれじゃなくてこっちの方がいいんじゃないかってなんか目覚めてしまって複数バージョン存在し始めたらもう終わりだよねおしまいですねやりきんないとなるほどねちょっと僕もいいっすかはい

ちなみに僕は実務で混沌としたものをクリーンアーキテクチャーに別のアーキテクチャーに書き換えたことはそもそもないですという感じなんですけど今関わっている案件の開発時期にアプリの開発しながらアーキテクチャーを整えながら進めていくみたいなことをやってたわけなんですけどその時の

ことを思い出しながらこうやったらいいんじゃないかと勝手に話すんですが野里さんがおっしゃってたように小さいところからやっていくっていうのが全てかなと思っててまず自動テストが完全にある状態っていうのを前提でちょっとずつこのオニオンアーキテクチャの状態を作り上げていくことをしていく

いくのかなと思ってます例えばデータベースの呼び出し部分をどこからも依存されないようにしたいってなった時にしたいというかそのモチベーションができるのは多分何かの機能回収もしくは機能追加がしてデータベースのクライアントに追加しなきゃ更新しなきゃってなった時にできれば全部全機能分のデータベースクライアントの呼び出し方を変えてあげる無理ならのりさん

同じように一時的に2個にして無理ならっていうかあれだな他の機能でもそれを触る予定があるとかであればやりきらなくてもいいかもしれないですけどできればやりきるぐらいの感覚でデータベースクライアントだけちょっと外出しして次に他のインフラストラクチャー外出ししてとかドメインモデルだけドメインモデルがどっかに依存する形を

辞めるみたいなそういう機能単位でちょっとずつリフォームしていくみたいなリフォームしていくみたいなやり方になるのかなと思いつつ多分それだと最終的に綺麗にはならないんですよ全機能を触るわけじゃないと思うんでで個人的にはそれぞれでいいんじゃねえかと思ってんですけどわかるはいであと

ごめんなさいちょっと最初に言えばよかったんですけどブランドデザインを誰かが作る必要があると思いますなんかこうなっていきたいよね将来的にみたいなそれがあった上でちょっとずつチームの意思として機能回収の度にちょっとずつ動かしていって最終的に一部いいけど一部ダメダメなキメラが出来上がるみたいな

っていうところが落とし所なんじゃないかなと思っててそれによってよく触る部分だけ綺麗になればいいのかなとかっていううんわかるなんかさ原理主義的な動き方は一番やめた方がいいなって思ってて例えばこういうアーキテクチャが世の中にあってこれが正解だからこれを目指そうみたいなのはなんか危険だなと思っててさっきのキメラの状態はなんやかんや

そこに落ち着いたらいいんじゃないかなって思ってるというかなんかさこの原理主義的にじゃあこの綺麗なオニオンアーキテクチャでやっていくぞってなった時にさマジでありえないぐらいファイル分割されて逆に分かりにくくなるパターンもあるなって思ってるね機能によってシンプルな機能だったら普通にトランザクションスクリプトで書いた方が良くないみたいなのとかここ最近あった俺の技術的な妥協なんですけど

なるほどね

っていうのが僕とのりさん的なこうやってやっていくんじゃないっていうお話でしたというのでちょっと締めでじゅんぺいに今週覚えた英語のフレーズ一つ教えてもらいましょうかsick and tiredsick and tired例文欲しいな何か聞かれたのどういう意味だそのままボアの

類義語みたいな言い換えみたいな感じなんですけどもう本当にうんざりしてるみたいな退屈だっていうその我慢の限界だみたいな熟語フレーズですねダリーとかじゃなくて日本語で言うと何が一番近いの?マジやばいじゃね雑すぎ多分そうだけど雑すぎ本当うんざりみたいなのが近いですねダリーはダルイナーは本当にダル

ダルっていう英単語D-U-L-Lそうなの?へーそんなのあるんだ多分ダルいは英単語が来てるのかなと思いますねそうなんだ知らんかったおもろこのコーナー面白いから恒例にしますこれは多分いくらでもいけますねはいというのでもしもさんお便りありがとうございましたありがとうございましたヒントになったらありがたいなと思いつつ結構前のお便りでもないか先月か先月のお便りなんで

今絶賛奮闘中かもしれないのでもし逆に知見あったら教えてください確かに年始のプランニング時期じゃないですかもしかしてかもしれないですね大応援しておりますありがとうございましたでは最後にお知らせでハッシュタグひまじんプログラマーでSNSネックスでフィードバック募集してますので本日のエピソードの感想もしくは何かそうですね

コメントとかありましたらぜひぜひお願いしますぜひ相談事でも送ってください英語はお任せあれいやー心強い普通にためになったもんね今の話あとはポッドキャストの説明欄からGoogleフォームで番組の要望・感想・質問お待ちしてますチャンネルの説明欄からスラックオンラインコミュニティひまぷろ談話室の参加申し込みフォームもありますのでそちらもお願いしますお願いします

最後に各種ポッドキャストプラットフォームのフォロー高評価お願いします励みになるんでぜひよろしくお願いします待ってますそれではまた次回バイバイやめてラーのバグ侵入の特殊能力でマスターザブランチが焼き払われたら闇のスパゲティコードと密結合しているじゅんぺうちの心までクラッシュしちゃうお願い死なないでじゅんぺうちあんたがここでクラッシュしたら先方との契約はどうなっちゃうのソースコードはまだ修正の余地があるここを耐えればコードを納品できるんだから

次回納期間に合わずデバッグスタンバイ