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
Nealle
March 07, 2025
Programming
0
750
運用しながらリアーキテクチャ
2025/3/7
事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線
https://timeedev.connpass.com/event/344976/
Nealle
March 07, 2025
Tweet
Share
More Decks by Nealle
See All by Nealle
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
2
13k
ニーリーにおけるプロダクトエンジニア
nealle
0
1k
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
150
事業KPIを基に価値の解像度を上げる
nealle
0
390
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
410
エンジニアが挑む、限界までの越境
nealle
1
910
ニーリーQAのこれまでとこれから
nealle
2
1.4k
データ分析で事業貢献するために
nealle
0
2k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
190
Other Decks in Programming
See All in Programming
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
12
7.4k
CIを整備してメンテナンスを生成AIに任せる
hazumirr
0
210
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
2
790
PHPカンファレンス関西2025 基調講演
sugimotokei
5
940
Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話.ai
fumiyakume
18
9.2k
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
10k
階層化自動テストで開発に機動力を
ickx
1
420
slogパッケージの深掘り
integral0515
0
130
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
150
TypeScriptでDXを上げろ! Hono編
yusukebe
3
870
可変変数との向き合い方 $$変数名が踊り出す$$ / php conference Variable variables
gunji
0
230
SwiftでMCPサーバーを作ろう!
giginet
PRO
2
190
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
77
9.5k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Why Our Code Smells
bkeepers
PRO
337
57k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
BBQ
matthewcrist
89
9.7k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Building an army of robots
kneath
306
45k
Transcript
運用しながらリアーキテクチャ Railsライクなフレームワークで構築されたサービスを運用しながら オニオンアーキテクチャにリアーキしていく 株式会社ニーリー プラットフォーム本部 アーキテクチャチーム 野呂 有我 2025/03/07 事業成長を加速する技術基盤
5社が語るリプレイス・リアーキテクチャの最前線
2 氏名 所属 経歴 野呂 有我 / Yuga NORO 株式会社ニーリー
プラットフォーム本部 アーキテクチャチーム ・大学院時代に友人と楽譜販売サービスを立ち上げ ・その後、SIer企業に参画 ・副業としてニーリーでいくつかの開発に携わる ・フリーランスを経て、ニーリーへ 1|自己紹介
目次 1|自己紹介 2|プロダクト紹介 3|DRFについて 4|起こった問題 5|意思決定 3 6| 振り返り 7|
まとめ・これからのこと
4 2|プロダクト紹介
5 3|Django DRFについて DRFは、超高速開発を可能にするPythonのWeb Framework Djangoのプラグインで、 View/Serializer/Modelの3つのパーツを組み合わせて、一瞬でAPIを構築できる 認証やユーザー管理、ファイルのアップロードに至るまで基本的には全て組込済み
6 弊社もその高速開発を利用し、機能をどんどん作り 急激なグロースを実現 • ・プロダクト開発人数が当初の 2人から20人以上にまで増加 • ・顧客も増え続け、機能開発のさらなる加速が必要になった 3|DRFについて
7 ・スタートアップは最初からそのサービスが成功するかどうかを知る術はない! ・できる限り少ないコストで、できるだけ早くサービスを、機能をリリースし続け、 結果として生き残ったサービスだけが「その先」を知ることができる! ・ 結果として「技術的な借入」が沢山ある状態に ・「借入」は「利息」を生み、開発速度が段々遅くなっていく 3|DRFについて
8 ・開発を止めたくなかった(止められなかった) → 移行中は機能開発が止まってしまう ・移行にかかるリソースも開発に回したかった → 開発アジェンダは増えるばかり ・性能的な面などで問題が起こっているわけではなかった → Python/Django/DRFに問題があるわけではない!
3|DRFについて
9 4|起こった問題 では、その時どんな問題があったか? 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3. キャッチアップ難度の増加
10 5|意思決定 意思決定 ・ある日、決済会計領域の大規模な改修が決定 ・そこで今ある問題↓をその領域に持ち込まないためにどうすべきかを考えた 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3.
キャッチアップ難度の増加
11 依存関係の複雑化/業務知識の分散/技術的関心との密結合 4|起こった問題
12 意思決定 依存関係の複雑化を食い止めるため以下のルールを策定 1. 別Appの関数への直接依存の禁止 2. 別Appのテーブルへの直接の書き込みの禁止 3. View/SerializerからDBへのアクセスを禁止 4.
SerializerはViewからのみ依存して良い 5. ViewはUrl.pyからのみ依存して良い 5|意思決定
13 意思決定 業務ロジックの分散と技術的関心との密結合を食い止めるため 1. View/Serializer/Modelへの業務ロジック記載を禁止 2. Usecase層という、業務フローを組み立てる層を追加 3. Domain層という、業務ロジックを記載する層を追加 4.
Domain層からDBへの書き込みを禁止 5. DBの読み書きが許される Infrastructure層を追加 5|意思決定
14 意思決定 これにより、各レイヤーの分担と依存の方向は以下のように 5|意思決定
15 意思決定 一般的なオニオンアーキテクチャーを採用 5|意思決定
16 意思決定 これを実現するために、 APIViewとserializers.Serializer以外の使用を断念😭 5|意思決定 一般的なオニオンアーキテクチャーを採用
17 意思決定 これを実現するために、 InjectorというDIコンテナ(のようなもの)を利用 https://github.com/python-injector/injector 5|意思決定 一般的なオニオンアーキテクチャーを採用
18 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった! 5|意思決定
19 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった! …が 5|意思決定
20 意思決定 ・今オニオンアーキテクチャ化しているのは この青い部分だけ ・その部分については見通しもよくなり、 参画ハードルも下がっていると信じている ・だが未だそうなっていない箇所の方が多い! apps/ ├── __init__.py
├── __pycache__ ├── business_crosscuing ├── cash_selement_common ├── client_analytics ├── client_manuals ├── core ├── core_system_link ├── coupon_page ├── customers ├── digital_cash_results ├── digital_cash_schedules ├── guarantees ├── libs ├── mypage ├── parkings ├── payments ├── platform ├── reservation_and_approval ├── selements └── users 5|意思決定
21 意思決定 5|意思決定
22 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 結局外からDBの値を書き換えられてしまう 5|意思決定
23 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 結局外からDBの値を書き換えられてしまう ・そこで、「Internal API層」を追加 ・これはマイクロサービスであればRPC(Httpなど)に置き換わっているはずの部分 5|意思決定
24 意思決定 5|意思決定
25 意思決定 5|意思決定
26 意思決定 5|意思決定
27 6|振り返りと現状の整理 結果、どうだったか?
28 6|振り返りと現状の整理 導入中 ・DRFの持っている便利機能を大部分捨てる判断のため、 最初はメンバーの反応が気になった ・最初のAppへの導入中は、書く量の増加が目につき不安だった ・最初はもっと厳格にオニオンアーキテクチャを 導入する予定だったが、 必要性の薄そうな部分を少しずつ削って柔軟にした ・この判断も実は少し不安だった
29 6|振り返りと現状の整理 導入中 ・「必要性の薄そうな部分」は、層ではなくルールの厳密さの部分 ・よく言われる完全性・純粋性・性能のどれを犠牲にするか? に加えて、最初のリリースタイミングが早まる選択 はどれか?をよく話し合った(トレードオフ) ・この時「借入メモ」を思いついていたらもう少し判断しやすかっ たかも… ※借入メモについては「開発 借入メモ」でググってください
🙏
30 6|振り返りと現状の整理 導入後 ・最初の導入プロジェクトに参加してくれたメンバーの反応は上々 だった(と思う) ・逆に考えることが減る ・レイヤーが増えることで変更がしやすくなる ・凝集度が高くなるため影響範囲の特定がとにかく簡単 ・というより、層ごとに単体テストがあるので、 影響範囲は勝手に特定される
31 6|振り返りと現状の整理 現時点での所感 ・この形がベストかはわからないが、既存の資産を捨てず、開発速 度も落とさずに(部分的にではるが)問題を解決できた ・もし、同じような課題を抱えている方や、 今後抱える方の問題解決の参考にしていただけたら幸い ・特にInternal API の考え方は、マイクロサービスとモノリスの
いいとこ取りができる可能性があり、おすすめ
32 まとめ ・FrameWorkを捨てる・捨てないの他に、 一部捨てるも判断としてアリ ・ルールは厳密に適用しなくても良いが、 トレードオフは考慮する。そしてコメントする。 ・モジュール単位でリアーキテクチャする場合、他のモジュールの 影響を受けないように層を設けるとヨシ 7|まとめ・これからのこと
33 これからのこと ・新しいApp領域を作成する場合にどんな規範に沿うか、 どんなアーキテクチャを採用するかは概ね決まった ・しかし、実際にはまだ最初に挙げた状態のままのAppが 沢山あり、そしてそれらの領域は大抵コア業務ドメイン ・次は、既存の部分をいかに漸進的によくしていくか、 というお話ができるといいなと思ってます 7|まとめ・これからのこと
ニーリーではプロダクトエンジニア、 その他のポジションも積極採用中です! https://jobs.nealle.com/ We are hiring!!!
Thank you 35