Todo

Todo	Done
アーキテクチャ見直しの話	o

Log

user-service / cms-service / chat-service みたいな操作する対象っぽいもので区切ってたやつ。

外からのリクエストは Ingress あたりでルーティングするので１ドメインだけど、内部的には入り口から小分けになってる。

デメリットは、内部だけで使いたい API みたいなのを作り始めると管理がしんどい

例えば chat-service で内部的にユーザ情報を user-service から引きたいときに userID を識別子として渡したいが、そんな API は外向きには開けたくないみたいな感じ。

Frontend + Backend が 1 アプリケーションの、アプリケーションが fe / be とかで別れてるやつ。be は CRUD 操作だけ、それを使って fe でユースケースを作る。

(user-fe / user-be) / (cms-fe / cms-be) / (chat-fe / chat-be) みたいな感じ。

人数が多いのであればこれでもいいんだと思う。

人数が少ない場合、共通化とかし始めてそれの反映とかに追われがち。

今までと違って、出面で Frontend をまとめる。Front(web-api, cms-api) / Backend(user-be / cms-be / chat-be) みたいな感じ。Backend は CRUD 操作だけ。

フロントの都合で勝手にユースケースを組めるので、比較的やりやすいかなって思った。

ただ実際やってみてわかったのは、ユースケースは大体似通うので、同じようなコードが生まれがち。こぴぺで横から持ってくる。

Frontend を出面でまとめて、 Backend を小分けにするの Backend が一つのアプリケーションにまとまっているというだけ。

Backend レイヤで共通で使いたいロジックとかが結構出てくるので、まとまってるほうが都合が良かった。

Frontend を出面でまとめて、Backend はひとつにまとめる案。 CRUD 操作だけのものを作っても、結局ユースケースによって前提となる処理があるので、それを各 Frontend に実装するのが億劫になった。

ユースケースを全部 Backend で切って、外からのアクセスに対しての認証とか、セッション検証とかだけ Frontend でする。

Backend を切り出しておくのは、認証を切り離したレイヤを用意しとくことで、バッチ処理とかでユースケース呼びたいときに使えるようにしておく。

ので、Backend では「誰のアクセスか」みたいな部分は検証しない。（必要に応じてロギングする）

アプリケーション側のクラス設計がちゃんと作れてなかったときに、モノリシックなアプリケーションを作ったら煩雑なものになった。

内部でぐちゃぐちゃしてシンプルを保てないので、アプリケーションを小分けにすることでシンプルにならないか模索してきた。

ただ、実際は人がたくさんいる会社だからできていたのであって、人が少ないところでやるものではないなってのがわかってきた。

また、user とかそんな小さい単位で単純に小分けにするのではなく、もうちょっと大きい概念で分けておくのが正しそう。サービス単位とか。