> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2021/w13-preliminary-assessment-for-architecture-selection.md).

# W13-アーキテクチャ選定の下調べ

今週、フロントエンド全体で使われている業務プロジェクトの構成をいくつか調べ、加盟店プラットフォームの選定に備えた。今のところ3種類を集めた。

オープンソースのフレームワークによる、ページ単位のマイクロフロントエンド。qiankunやgarageなどを使う。代表例はM側のアプリが多く、エコシステムのCMMや諸葛プラットフォームなどだ。

EDCによる、コンポーネント単位のマイクロフロントエンド。代表はエコシステム金融のMFCである。安定性と可用性は、C側の提携カードで一定程度確認され、外部へ提供するプラットフォームへの転換期にある。接続・改修の費用は、まだ調べる必要がある。

Nodeによる、複数ページのアプリ構成。代表はC側の資産運用のCORPSだ。業務フローの分割と自律性を解く。加盟店プラットフォームの課題は、主に横断的な業務の結合であり、縦のフローの最適化はそれほど切実ではない。

私たちの人員が限られ、業務も止められない状況では、価値の優先順位は費用、安定性、性能になるべきだ。費用には、既存プロジェクトの移行費と、保守・チームの理解にかかる費用の2つがあり、いずれも低くしたい。安定性は、まず構成そのものの安定性で、少なくとも現在と同等を求める。変更後は各サブサービスが自律するので、開発全体の安定性は大きく上がるはずだ。性能は新構成の到達上限を指す。今の性能自体がまだ高くなく、改善余地が大きいこと、B側はC側より性能への許容が広いことから、適度なトレードオフは可能だと思う。