本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの4日目の記事です。
3日目は、bigwheelさんの「集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話」でした。
5日目は、yoskhdiaさんの「エンティティの同一性を表現するためにequalsをオーバーライドすべきか否か」です。
Microservices の利点
- 技術異質性
- 回復性
- スケーリング
- デプロイの容易性
- 組織面の一致
- 合成可能性
- 交換可能にするための最適化
Monoliths, Microliths での境界づけられたコンテキストの統合
Monoliths
Monoliths なアプリケーションに複数の境界づけられたコンテキストを統合するケースでは、共有ライブラリや、モジュールによって 分散コンピューティングで遭遇する煩わしい問題の多くを回避できます。
Monoliths なアプリケーションの欠点は、変更した場合にアプリケーション全体をデプロイしなおす必要がありデプロイ容易性に欠けるという点です。 このことから頻繁なデプロイを行うことが少なく、時間の経過とともに技術的負債が蓄積され、変更がさらに困難となっていきます。
Microliths
Monoliths なアプリケーションのケースでも、必ずしも一つのアプリケーションで構成されるわけではなく、日次、月次、年次等のようなバッチ処理アプリケーションとWebアプリケーションのように、複数のアプリケーションに境界づけられたコンテキストが統合されます。
これをさらに細かく分割して Microservices と似た構成のアプリケーションに分割することもできます、分割したアプリケーションで次のような問題が発見されることがあります。
- アプリケーション間の結合度が高く、いずれかのアプリケーションの障害により分割した他のアプリケーションに影響を与える
- 類似のロジックが分散していて、あるアプリケーションの変更を、他のアプリケーションでも行う必要がある
結果として、分割したアプリケーション単体でのデプロイは困難となり、複数のアプリケーション、最悪の場合は、すべてのアプリケーションを同時期にデプロイしなければならなくなります。
このように分割されたアプリケーションは Microliths と呼ばれます。
Microservices
実践ドメイン駆動設計から、Microservices としての利点を満たすアプリケーションにとって特に重要なポイントをピックアップしてみます。
第2章 ドメイン、サブドメイン、境界づけられたコンテキスト
Microservices ではアプリケーションと組織面の一致が必要です。したがって、ドメイン、サブドメインや境界づけられたコンテキストと組織面の一致がないと、不要なドメイン知識まで取り込むことになったり、ドメインの知識を、外部のコンテキスト - つまりは他の Microservices - に依存しなければならなくなり、自律的なサービスを実現することができなくなります。
第13章 境界づけられたコンテキストの統合
Microservices として自律的なサービスを担保するためには、境界づけられたコンテキストの統合にメッセージングが最も有力な候補となります。
第14章 アプリケーション
Microservices に統合する、複数の境界づけられたコンテキストは組織面と一致させる必要があります。
まとめ
Microservices に分割したアプリケーションがうまく機能しないというのを見聞きすることがありますが、これは、Microservices だからということではなく、 境界づけられたはずのコンテキストの境界があいまいであったり、ドメイン、サブドメインについての考察が十分ではないことが原因の多くをしめているのではと考えています。 Monoliths であればそういった誤りは技術的負債として将来に繰延べされますが、Microservices の場合は初期にこのような問題が発見されるため、設計に対するフィードバックを早めることができるという利点もあると考えています。