⾃⼰紹介 l LINE Fukuoka 株式会社 l 2016年⼊社 l 開発1室 Dev K team Manager l Server-side Engineer l 2 kids l Interests/Hobbies l Exercising / Marathon l Twitter: @hkazushi0627 ฏҪ Ұ࢙ ,";64)*)*3"*
l マイクロサービスやコードベースの学習が困難 l リポジトリ上のコンポーネントが多すぎる l それぞれのコンポーネントが、どのプロダクト、どの機能を担当するのか不明確 l 各コンポーネントの担当者が不明確 l コンポーネントについて質問したい時、何か変更を⾏ってソースレビューしてほしいとき、だれが適切なのか不明確 Problems チームの新メンバー チームの既存メンバー l 担当したコンポーネントは限られるため、新メンバーと同様の問題を抱える l 実はマイクロサービスの全体像を知っている⼈はだれもいない これらの問題をどう解決して、複雑になったマイクロサービスをどう管理していくか︖
l コンポーネントを論理的にグルーピングする l グループ = コンポーネントドメイン l ハイレベルな図を扱うことで、複雑ではなくなり、全体把握の学習コストが下がる Solution: Component Domain コンポーネントドメインの導⼊ ハイレベルアーキテクチャ図 Storeドメイン︓コンポーネント図
l プロダクトや機能、もしくはコンポーネントの責務 l ストレージやキャッシュレイヤーはドメインごとに閉じる l ストレージやキャッシュの障害の影響範囲は、ドメイン内のコンポーネントのみ l ドメインの開発を、プロダクト・フィーチャーチームにまるごとアサインできる l 担当ドメインの開発に集中できる l ストレージやキャッシュの担当ドメインが明確に定義され、内部、外部の依存関係も明確 l 明確な定義により、⽇々の開発だけでなく、緊急時の対応も円滑に⾏える Component Domain – How to define LINE STOREのWebアプリケーション部分が責務 ストレージやキャッシュへのアクセスは、Storeドメイン内のコンポーネントのみ それ以外は公開されたAPI経由で、アクセスする LINE STORE Devが開発担当 どういう単位で、コンポーネントをドメインごとにグルーピングする︖ 課題
l アーキテクチャのリファクタリングを⾏う l 別ドメインからは公開API経由でデータにアクセスするようにする l データベースをドメイン毎に分割する Component Domain - Refactoring 複数のドメインから同⼀のストレージにアクセスしている場合は、どうする︖ 課題 公開API経由でデータにアクセス データベースを分割 xxxドメインのコンポーネントが、yyyドメインのストレージにアクセス
発表の流れ l コンポーネントドメインを導⼊して、マイクロサービスをグルーピングする l コードベース上で、ドメインを表現する、担当者を明確にする l ドメインはプロダクト、機能、責務で分割する l データはドメインに閉じることで、耐障害性や開発効率が向上する l 正しいドメイン構成にするために、アーキテクチャのリファクタリングが 必要なケースもある まとめ
policemankh
mitsuakitohei
line_developers
soudai
codmoninc
i524
yoshiitaka
claudioed
bonotake
ama_ch
yokawasa
yosuke_furukawa
pauli
panda_program
maltzj
jrom
morganepeng
chrislema
edds
trishagee
keithpitt
jonyablonski
ddemaree
jponch
ufuk