Eberhard Wolffさんのこのプレゼンの要約です 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、すべてのサービスのデプロイを伴う (Kafkaのようなストレージに格納された)イベントを共有するのも同じ マイクロサービスに閉じたローカルデータモデルを使う そうするとシステム全体でのデータモデルの数は増える。 これは独立性と共有データモデルのトレードオフである 1つのコンポーネントの障害が、別のサービス群にに波及していく 別のマイクロサービスに障害が発生しても、他のサービスは動き続けられるように設計する 与信が障害発生中で注文を全部受け付けられなくても、ある上限額までは受け付ける、とか 決して呼び出し側を永遠に待たせるようなことがあってはならない ネットワークトラフィックによる性能問題やレイテンシの増加につながる。 ドメインの独立な部分は、他とのサービスとのやりとりが発生しないことを意味するから。 ドメインオブジェクトの1つ1つをマイクロサービスとすること マスタ的なエンティティのマイクロサービスにアクセス集中することになる レジリエンスの観点からも、障害が波及しやすい構成になる 代わりに1つのデータベースを、複数のマイクロサービスから覗きにいく方式が考えられる が、共通データモデルやレジリエンスの問題は解消できない マイクロサービスは閉じた固有のデータモデルをそれぞれで持つように設計する。 最悪、データベースを共有したとしても、スキーマはサービス毎に分けてる 「システムは柔軟でメンテナンスしやすいだろう。なぜならマイクロサービスアーキテクチャだからね」 複雑な依存関係そのままに、モノリスをマイクロサービス化しても、構造的には何も変わらない。 マイクロサービスは、モジュールの別の一表現に過ぎない マイクロサービスだけでは、高い結合性や低い凝集性を改善できない 泥団子をマイクロサービス化しても、ちょっと小さな泥団子がたくさんできるだけだ Bounded Contextを設計する: 1マイクロサービスで完結したドメインモデルになるように Bounded Contextごとにマイクロサービスに移行する アーキテクチャ構造を修正したければ、マイクロサービスはその助けにはならない。 アーキテクチャ構造を修正したければ、そのアーキテクチャ構造を修正しよう。 
