マイクロサービス
なぜ分割するのか
空間が分かれる
メリット
認知が下がる
命名が楽になる
デメリット
分かれたら、認知の外になる
本来適切にみんなが分割してくれたら良い。
パーツを組み合わせるゲーム。
software engineeringではパーツを自分で作れる
w/ 関数定義。 w/ クラス定義
パーツ次第で組み合わせがかわる
基本的に「組み合わせられるか？」が大事
LEGOは結合部分の形が決まっているからパーツが増えてもくっつけられる
推論APIもそう
Amazonが無限に企業を拡大していくことに成功した「ピザ2枚ルール」 - GIGAZINE
どのエンジニアにも「顧客⇄開発⇄システム」のサイクル（フルサイクル）を全部担当させる
参考）Netflixにおけるフルサイクル開発者―開発したものが運用する - VOYAGE GROUP techlog
ここは譲らない。
伝言ゲームの入る余地をなくすことで「service(とその未来)に最善なsystem」を作る
全部担当させるためにも…1事業/serviceを細かく分割する
microserviceという。
microservice自体は…顧客に直接価値を与えない。
microservice全体で一つの価値を顧客に提供する
microserviceはただのsystem分割ではない
ここの分割が…とても難しい
ただのsystem分割になってはいけない。
system分割では…担当するengineerの負担が下がらない。
engineerが「一つの小さいフルサイクル」に注力できる状態にする必要がある
「それだけを意識していればいい」くらい綺麗な分割をする必要がある
ここの考え方もオブジェクト指向にちかい
一番近いのはコンポーネントに関する6つの原則 - Qiita
system分割にならないように
microservice(と担当engineer)は、microservice外のことはほぼ意識しなくて良い
具体的には
service間の連携はWeb APIで行う
DBを共通で使うことなんてアリエナイ
Engineer/ Operatorも、他serviceの人とのCommunicationはほぼしない
使っているIT infraもServiceによってバラバラ
さあ、そんなmicroservice分割をどうやればいいのか…？
そこで使われるのがドメイン駆動設計
そもそも
IT systemは「存在する業務processをsoftwareで肩代わりするもの」にすぎない
IT systemの大きさ/分割しやすさは「元々の業務Process」に大きく影響する
業務Processの基礎となる業務知識(=ドメイン知識)を起点にsystem開発をすることで、
「systemを作っても…数年・数十年変更がなさそうな部分」を想定できる
見えてきたDomainの特徴に合わせて、それを小さな単位（sub domain）に分割できる
business sideとengineer sideが共通言語を持てる
business sideの要求に対してengineer sideが背景を想像できるようになる