アーキテクチャ
システムの全体構成
コードの管理とかデプロイ単位、app(モジュール、サービス)の分け方なんかのイメージ
考慮すべき点 構成に依存する部分
リポジトリの分割単位
テスト、デプロイ
流れ的には
モノリシック
把握する範囲が狭い場合は開発がはやいのでメリットが大きかった
だんだん機能がふえてモジュールが複雑化していくと影響範囲が大きくなり追加改修に時間がかかる
マイクロサービス
影響範囲を狭めることで手軽にデプロイできるようにするのがおそらく主目的
その際、appの分割単位を鑑みるに依存しあわない範囲で切り出すドメイン、サービスという境界が意識されることにもなった
反面、分けたことでサービス同士でのインターフェイスやサービス管理・監視の重複が多くなり、主にコミュニケーションのコストが大きくなる
また、コードだけでは全体把握が難しくなるため。図や
モジュラモノリス
アーキテクチャの名称と特徴
モノリシック
デプロイ単位とモジュール(app)が同じ
モジュール内に複数のサービスがある場合には、影響範囲が大きくなり、気軽に修正、デプロイすることが困難になり提供速度は遅くなる
スケールさせる効率も悪い
マイクロサービス
デプロイ単位とモジュールがドメイン、サービス単位で分割されている
個別でデプロイ、管理できるので考慮する影響範囲が小さい
反面、モジュール間のインターフェイスを把握、考慮する必要がでてくる
スケール効率が良い
モジュラモノリス
デプロイ単位は大きいままで、モジュールの分割単位をサービスにするようなイメージ
リポジトリは同一になるため、コード管理が煩雑になりづらい
モジュール構成のルールを規定、適用させる手間が大きい。マイクロサービスは強制的に境界が発生するが、モジュラモノリスでは境界をコード設計に落としている
モジュール間の依存を管理する。パッケージの依存関係
ミニサービスアーキテクチャ
分割単位をドメイン単位とする
DBは共通
app間の通信はイベント駆動や、httpなんかで