本ブログで何度かマイクロサービスについて取り上げてきて、下記の記事でメリットなど書きました。
https://toaruit.hatenablog.com/entry/2017/07/09/234957
システムを自社で決めた「サービス」単位で区切ることにより、サービスの追加・変更が行いやすくなり、結果として変化に強くなる構成となります。
【Oisixが19年運用してきたモノリシックなサービスのマイクロサービス化を進め、Kubernetesを本番運用できる理由】
https://www.itmedia.co.jp/enterprise/spv/1903/18/news016.html
マイクロサービスと対比されるのが、モノリシック(モノリス)なシステムになります。モノリシックは一枚岩という意味で、一つのシステムの中で使用する機能やサービスが、全て盛り込まれてる構成を指すことが多いです。
【モノリシック】
https://www.weblio.jp/content/%E3%83%A2%E3%83%8E%E3%83%AA%E3%82%B7%E3%83%83%E3%82%AF
さて、マイクロサービスを採用する際に、モノリシックの欠点ばかりがクローズアップされますが、双方メリデメがあって一概にどちらかが正しいとは言えないと感じています。下記の記事では、マイクロサービスの課題的なことが書いてあって、マイクロサービスで課題となる部分がモノリシックの利点になったりします。
【これなら分かる！ マイクロサービス（入門編）～モノリスと比較した特徴、利点と課題】
https://codezine.jp/article/detail/11055
システムが小さいうちからマイクロサービスを、適用するのではなく、大きくなるにつれて徐々にマイクロサービスに移行するのがよいかなと感じました。
下記の記事では、環境は単一であるものの、内部の実装でサービスを意識した設計にしているそう。こういうところはDDDの知見があれば、活かしていけるのでは、と思います。
【Shopifyはいかにしてモジュラモノリスへ移行したか】
https://www.infoq.com/jp/news/2019/10/shopify-modular-monolith/
