microservice
なぜやるか
- 機能開発を迅速に進めていくため
- 開発組織をスケールアップしていくため
やる場合守りたいこと
- 他のチームのコードは変更しない、そのチームに対して修正依頼を投げる(機能に責任を持たせる)
-
他チームのライブラリに依存する。チーム間でお互いに影響するような依存は作らないようにする
- ライブラリ変更の際にコミュニケーションが発生してしまう
-
ステークホルダーはチームごとに分ける
- そもそも、モノリスが辛くなってくるのは大きくなったシステムに対して利害関係者が増えてきて意思決定に必要なコミュニケーションが増えてしまうこと。そのため、チームの意思決定に必要なステークホルダーが他のチームにも依存する場合は前者の問題が解決されていないように見える。
- 社内のステークホルダー、機能が提供する価値を受け取るステークホルダーの 2種類がいるとも考えられるのかどうか疑問ではある。
メリット
上記のことができているとすれば
-
チームで迅速に(ある程度)意思決定し、独立して動ける
- ある程度 → インターフェースやその仕様、 UI 実装依頼などチーム横断で話すことはあるはず。ただ、これを極力少なくするようにデザインする。
- 独立したチームを増やして行ければ、チームの人数単位でスケールが可能になる
疑問
耐障害性を考えてサービスを切り離すのはありなのか。必ず守りたい api を分離するなど。
その他
ステークホルダが多岐に渡らなければ microservice 切るほどでもない。よく ddd で出される例でいうと、ビジネスの範囲で oo部門 → xx 部門 をまたぐようなシステムを作る場合には microservice でそれぞれ独立して動けるようにしてもいいのかもしれない。が、それでも最初はモノリスで様子見がよさそう。もしかしたら部門がくっつく可能性もある。
切り離すのは、それぞれの部門でやりたいことが増えてきて、チームの人数も増えてきたときにより早く動けるよう必要な部分に境界線をおいて分けるのがよさそう。
明確に価値提供するエンドユーザが異なる場合も検討してよいかもしれない。例えば、EC の決済機能は Consumer であるが、EC の商品管理機能は Shop 向けの機能である。しかしここで難しいのは、商品は Shop でも扱うし Consumer も見るということ。こう考えると明確にわけるかどうかはトランザクションの範囲など技術的な詳細を詰める必要があるかもしれない。そんなときはとりあえずモノリスでよさそう。ここで頑張って microservice にするのは、EC 以外でも決済を提供する場合には単機能として切り出してもよいのではないか。あるいは決済の負荷が高くなるのは目に見えてるのでスケールしやすくしときたい場合など。
参考
cdk
Cloudformation を書くより数倍楽。新規で IaC やるなら断然これ。以下よきポイント(Typescript で書いた所感から) まだ書き始めて間もないので辛みにはあたっていない。
- コード補完最高
-
vscode 上で定義先にコードジャンプできる
- Cloudformation では AWS のリファレンスを都度ググったりしていたが、この作業省けるのが楽。例えば、ec2 の設定として何ができるんだっけにすぐアクセスできる。
- ライブラリの doc が見やすい。こんなページなのだが、定義調べたいときにすぐアクセスできる。
-
既存のリソースを FronArn などで参照できる。
- Cloudformation の output とか使わなくて済んでいる。
- スタックを小さく保つことができそう
- Typescript そんなに知らなくても大丈夫。cdk は Typescript の型をうまく使って、開発者に事前に間違っていることを教えてくれるだけ。ある程度コード書ける人なら型を見て必要な値をいれておくだけでよい。
モデリング勉強会
最近 2 連続でモデリングやってみた。モデリングとは、達成したいユースケースを考えるときに登場人物や必要な概念、つながりを明確にすることだと僕は考えている。
結論、課題の対象ドメインに対して人と話しながら合意して進めるのは非常に効果的だなと感じた。
モデリングは設計と同じ作業であると僕は考えているので、設計段階で合意できていなければ、コードが間違っていることや、テーブル構造が間違っていることは明白である。
それなのに、テーブル構造から話を始めたり、コードから書き始めてしまうことがある。僕もそういうことが多かった。テーブル構造の設計時も何が達成されていなければならないかが明白になっているので本当にそれが正しいかわからなかったりする。
しかし、本当に大事なのはテーブル構造ではなく機能的に達成したいユースケースである。ここを明確にモデリングせずに、テーブルを考えてしまっても抜け漏れがあとから発覚する可能性は高いだろう。
そのため、複数人でモデリングを行って大前提の設計に合意するのはその後の作業がスムーズになる。設計のコンテキストを最初から共有しておくことで仮に実装を別の人がやることになっても大きくレールを外れることはない。
僕はその時点でベストなものを作っていきたいので、ある程度は考えておいて、色んな人から意見をもらってから実装に移っていこうと改めて思った。そしてこれは自分の成果物を見る可能性がある人は必ず巻き込んで実施する。前述したとおり、成果物の認識を設計段階からかっちり合わせていくため。