ろくにモジュール化がされておらず、すべての機能は密結合であり、特定の機能の修正があまりにも困難であったコードベースを持つ企業（前職）から、逆に、初めから、あらゆるものをモジュール化 -- マイクロサービス化している、まるで正反対のアプローチをとる企業（現職）へと移った身として、さて、現職は何を解決しているのかということを考えてみたいと思います。
私が苦しんでいたこと
前職で苦しんでいたのは以下のようなものです。
- 不適切な一般化
- （上とは逆に）一般化すべきものを一般化していない
- 無秩序なデータアクセス
...他にもありますが、割愛しましょう。
不適切な一般化
例えば、「見積機能」が「注文機能」を継承しているというのをみたことがあります。
見積というのは、支払-役務提供関係を結ばないだけで、買い物カゴの中に商品を入れて、その合計金額を算出して、何らかの「書類」を出すという点で、注文と全く一緒だと考えたのだと思います。
さて、実際のところは「全く同じ」なわけはなく、見積においては有効期限があるとか手動割引登録があるとか、業務フローが分かれているだけあってそれぞれ異なる論理があるわけで、それを無理やり統合した結果はあまり良いものではありませんでした。見積フラグみたいなのがあらゆる関数に生えてました。
一般化すべきものの一般化不足
恐ろしい一般化がされているのに、なぜか欲しい一般化はされていなかったりします。
主に、ライブラリが担当している部分なのですが、メール送信ライブラリを直接使って、多くの箇所でメール送信を呼び出していました。
「もはやサポートされない」という状況になってメールライブラリを入れ替えなければならなくなった時、全てのメール呼び出し箇所を洗い出す目に遭いました。
無秩序なデータアクセス
LaravelのEloquentみたいなものがあると、至る所で Product.find() のように取得ができて、挙句、product.save() とかで更新までできてしまいますよね。
それなりに複雑なアプリケーションになってしまっていたので、適切に where 句をつけてやらないと、変なもの取得してユーザーに表示してしまうといった問題はよくありました。その時、SQLもどきのコードとか上記のようなインスタンスに生えてる便利メソッドを使ったコードとか、至る所にあるものですから、それぞれでの使いかたを目視確認して、where 句をつけて回るようなことをしていました。
何を解決したかったのか
上記の経験があったものですから、私は、ドメインごとに切り分けして、モジュール化し、ある種、お互いを侵害しないような形式にしたいと思ったわけです。その時、マイクロサービス全振りというのは、なかなか私にはエレガントな解決策に見えたわけです。
マイクロサービスが解決したもの
さて、現職は上述の通り、マイクロサービス主体というコードになっています。各マイクロサービスは自分のところのデータを、自らのAPI経由でしか触れないようにしていますから、お互いが雑に侵害される可能性もありません。
メール送信機能みたいなものも一つのサービスとして切り出していますから、各サービスはメールを呼び出したくなったらメールサービスのAPIを呼び出せばいい -- メールライブラリの心配はメールサービス側が見てくれる -- といった綺麗な分業体制が引かれました。
私は、前職の苦しみからは解放されたわけです。
新しい苦しみ
とはいえ、「銀の弾丸」というものはなかったわけです。
あらゆるものをマイクロサービス化したことで、マイクロサービスごとに独立したチームが出来上がりました。（もしくは、逆かもしれません。チームごとにマイクロサービスが生えているのかもしれません。）
それぞれのマイクロサービス（マイクロチーム）は、それぞれ機能開発をしていくわけですが、結局、「製品」としてみた時、それらのマイクロサービスというのは、現実の製品にするために「糊づけ」を必要とします。それは、チームの垣根を超えた「コミュニケーション」と「責任共有」を必要とします。
これは、私が分割がなく、カオスをカオスのまま残した前職では気にすることもなかったことです。
この「責任共有」は、カオスなそれと比べて、より強いカリスマ性...プロダクトマネジメント能力を必要としているように思います。そうでなければ、各マイクロチームは個別最適を目指し、その果てに「2つのサービスを適合できる糊がないので、アダプタを作ります」を繰り返すことになります。
どうするのがいいのか？
マイクロサービスは、後から導入するものなのでしょう。カオスになっていたものの一部を切り離す、もしくは、もっと適切な使い方は、独立してスケールしなければならないものを切り離す。ただそのために使うものなのでしょう。
より良いアプローチを目指して
現職においては「糊付け」を書かなければいけない時以外の認知的負荷は極小化されています。よって、一定の評価はしたいのですが、もう少し、中間的なものを目指していきたいところです。
以上！