第３章：Defining an Event-Driven Microservice and Its Boundaries
の3.2の読書メモ
要約
イベント駆動型のマイクロサービスの境界を定義するアプローチについて紹介
境界を定義するアプローチ
1. ドメイン駆動設計（DDD）
- ビジネスのドメインに基づいてサービスを分ける方法。
- 安定性が高く、組織構成とも相性が良い。
- 各ドメインが独立して進化できるので、変更の影響を最小限に抑えられる。
DDD根強い人気ありますね。複雑さを受け入れて立ち向かう武骨の設計～実装論。あの分厚いエヴァンス本を見た人が果たしてどれほどいるのでしょうか。。（私は見てないです）
2. 組織構成（Conwayの法則）
- 「組織が設計するシステムは、その組織のコミュニケーション構造を反映する」
- チーム構成が技術的な境界に影響を与えることがある。
- チームの自律性を高めるために、組織構成に合わせた境界も有効。
これはもう避けられない影響がある。責任範囲が組織として表れるので実際のところシステムのあるべき論より、そのシステムを使う人たちの責任の範疇で運用できるように分けることが多い。あるべきシステム像からチームを設計する逆コンウェイの法則という考えもあるが、組織いじり過ぎてよくわからなくなることも多い。
3. 変更の可能性
- よく変更されるサービスと、あまり変更されないサービスで分ける方法。
- 観測範囲では最適化されて一定有効。
- ただし、境界の再編成に手間がかかる。
これは、ローンチまではうまくいくけど運用始まって新しい機能入れるときに固定化した塊に苦労することある印象。
4. データの種類
- PII（個人識別情報）やPCI DSS、PHIなどの機密データを扱うサービスを分離。
- 規制対応（例：GDPR）を限定的に適用できるので、管理が楽になる。
これはあまりやったことないけど、実際にやることなったら参考にしたい。要するにそのデータを扱うサービスだけ切り出して専門的な運用するということかと。
✅ まとめ
境界の定義には1つの正解はなく、状況に応じて複数のアプローチを組み合わせるのがベスト。ドメイン、組織構成、変更頻度、データの種類などを考慮して、柔軟に設計しましょう。