昔、オライリー「マイクロサービスアーキテクチャ」を読んだ後は、サービスはライン工みたいな感じで考えれば良いかなという解釈。
細かく分けすぎず、スケーラビリティーを意識して…設計してきたつもり。

一方、オライリー「ドメイン駆動設計をはじめよう」を読むと、コンテキストの境界に合わせると良さそうな印象を受けた。
しかし、コンテキストには規模があるので、規模によってはライン工のような配置が望ましい。
…が、DDDはユビキタス言語の話もあるので、コンテキスト内のサービスは統制が必要。

申し訳ないけど、MSのデモで「いくら何でも分解しすぎでは…？」と感じてモヤモヤしていたから、原因がわかって良かった。
ググると、分解しすぎてグチャグチャなマイクロサービスアーキテクチャに対する批判みたいなブログ記事があったりしたので、学び方が大切なのだと思う。
一連の処理を頭の中で製造ラインに置き換えてイメージすれば、行き過ぎた分解は避けられると思う。

さらに、オライリー「大規模データ管理」を読むと、コンテキストにデータプロダクトも加わるので…管理としては、コンテキストあたり複数コンテナの構成が良さそうな印象。
加えて、APIを統括するサービスも境界に配置した方が良さそう。
書籍では、データ処理はAzure Data Factory内で行っているようだから、データベース同様に依存関係は別で管理しているのだろうけど。

データプロダクトを考えると、アプリ側がデータベースの内容が抽象化されるような高水準なフレームワークを使うのは微妙な感じ。
サービスは応答性が重要なので軽量な方が良い。

PythonならFlaskなど。ORMは要らない。
.NETはAOTを使える場面が増えれば良いが…何かというと、AOTではビルドできないことが多い。将来に期待。
Node.jsはバイナリーで動かない時点でアウトだけど、Web UI寄りの処理をするサービスではベストな選択肢。
総合的な応答性を高めるならGraphQLも選択肢に入る。
突き詰めていくと、Goがポピュラーなのは自明か。

あくまで、上記はマイクロサービスアーキテクチャの場合。

もっとも、何でも「APIサーバー側で」という考えがどうかと思うが、未だに根強く残っている気が。
GraphQL、WebAssemblyなどでリソース負荷をフロント側に持って行く方が良い。