切り口
「必要十分な」ドメイン設計は有効
- 正しい境界を設定することがマイクロサービス化の一歩
- 「集約」の手法が有効
- 実際のドメイン概念の表現
- 一般的にライフサイクルを持つのでステートマシンとして実装できる
- 外部からの不正な状態遷移要求に対してバリデーションができる
- 集約の集合が「境界づけられたコンテキスト」
- 集約もコンテキストも一種のサービス境界として機能する
- あくまでも「切り出し」を目的としたDDDの適用であって、DDDをやることが目的でない点に注意
- 分離の起点を判断するのに必要十分な情報を得られればよい
- イベントストーミングの手法を取り入れるのもよい
- システムでどのような(論理的な)イベントが発生するかを理解することに焦点を当て、システムのステークホルダーとして関心を持っている事実を特定するもの
- https://qiita.com/tsukmr/items/91f5be9ba1004c19ec26
- https://yoskhdia.hatenablog.com/entry/2018/11/09/200556
- 分離しやすさと、分離によって得られる利益で4象限を作ってもよい
マイクロサービスは手段の一つでしかない
- ビックバンリプレイスの後には何も残らない
- メリットとデメリットを見極めて小さく始める
- FBが早く得られるほうが学びを得やすい・活かしやすい
- マイクロサービスだけが正解ではない
- モジュラーモノリスとか
- そのままでは「分けないほうがいい機能」とか
- 依存するサービス量が多い通知機能のようなものとか
進め方
コンウェイの法則
- フロントエンドチーム、バックエンドチーム、DBAチームと組織が分かれているなら、アプリケーションもそのようになっている
- これは新機能開発のときにすでにある層を横断して開発をしないといけないことを表す
- 新しいプロダクトの形に合わせて組織も再編し、責任を再割当てするとよい
John Kotterの組織変革のための8段階のプロセス
by 企業変革力
既存システムのどこに痛みがあるのかを考える
- 現在のペインポイントがどこで
- どのような変化をもたらすことを望んでいるのか(ビジョン)
- どのように目標に到達するのか(戦略)
- をまとめる
本番投入しないとわからないことのほうが多い
- どんなに小さい規模でもデプロイまでを1セットにする
- たとえアクセスがこないとしても
- ブランチアウトした先で長く作業をしすぎないこと
あとは小見出しの通り
- 一人でがんばってもうまくいかないのでビジョンと戦略をまとめて巻き込む必要がある
- これは偉い人の口から言う
- 小さく初めて短期的成果を得る・そこから学ぶ
- 定期的なチェックポイントを設ける
- 定量的・定性的
- 定性面では「このPJ、うまくいってると思う?」とかでもいい
- マイクロサービス化は「可逆的」
- うまくいかなければ戻せばいい
- 大きな投資を伴うような選択の場合は可逆性が失われるのでちゃんと判断しよう
- 正解がわからない場合は「わからない」って言っていい
- 解決したい問題と迷っているポイントが周りに伝わるということが利点
- そのうえでその時点で正しいと考えている対処を始める
- 時間(がもたらすスキルや経験)が解決の糸口になるかも
移行手順
後戻りの道を潰さない
- リファクタを行うなら、リファクタ前後の実装を残して切り替えられるようにしておく
- プロキシなどを用いる
- 移行中のサービスがあるなら、完了するまではそこへの新しいフィーチャやバグ修正が入らないようにする
- 移行とフィーチャの取り込みを並行してはならぬ
- ロールバックしにくくなるので
- とにもかくにも「インターフェイス」
事例:Squareの「注文」
- 客にとっての注文と
- レストランにとっての注文と
- 配送ドライバーにとっての注文
- それぞれニーズが違うのに、ひとところにまとまってしまっており、デリバリー衝突が起きていた
- 分離によってワークフローを分割しつつスケーラビリティと堅牢性を担保しようとした