このページの目的
コンポーネントのドメインが名前空間によって明確に分けられてる場合、そのコンポーネントの分離をサービスレベルにまで分離し、サービスベースアーキテクチャを構成する。
参考記事
本記事は以下の二冊をもとに作成しています。アーキテクトを目指す人に対しておすすめの二冊です。
気になった方はこのページから購入していただけると自分に少しお小遣いが入るので差し入れとしてお願いいたします！
サービスベースアーキテクチャとは？
サービスベースアーキテクチャは、マイクロサービスアーキテクチャの要素もある、分散型のアーキテクチャだ。
しかし、マイクロサービスやイベント駆動のタイプに見受けられる複雑さやコストがなく、多くのビジネスアプリケーションで選択されている。
構成要素は3つ存在し
個別にビルドされたユーザーインターフェース
個別にビルドされたリモートのバックエンドサービス
モノリシックなデータベース
これらがユーザー側から見て順にレイヤーとなり構成される。
なぜサービスベースアーキテクチャなのか？
サービスベースアーキテクチャはデータベースの分離までは行わない。 このことから、最も難しいデータの分離を行わずにサービスを分割できる。
加えて、アーキテクトと開発チームがドメインに関する知見を深めて、それらをマイクロサービスのように完全に分離するべきか、 あるいは大きなドメインサービスとして残すべきかを判断できるためだ。
サービスベースアーキテクチャへの移行で注意点1:細かくしすぎない
サービスベースアーキテクチャへの移行は、最初からサービスを細かくしすぎない様にしておく。
サービスを細かくしすぎるということは、本来であれば必要のなかったコネクションが発生することを意味する。 例えば、データ分解、分散ワークフロー、分散トランザクション、運用の自動化、コンテナ化など。 これらの作業が発生しデメリットがメリットを上回るのであればモノシリックな状態のままの方がマシになる。
サービスベースアーキテクチャへの移行の注意点2:全体を把握してから行う
サービスベースアーキテクチャへの移行の取り組みは、全てのコンポーネントドメインが特定され、リファクタリングが終わるまでは適用するべきではない。
理由は作業量を減らすためだ。 もし仮にコンポーネントドメインを特定せずにサービスの移行を行ってしまい、後から移行する必要のあるコンポーネントを発見した場合、 そのコンポーネントの修正とサービスへの統合が求められてしまう。 場合によってはサービスの名前まで変更せざるを得ない状況になるかもしれない。
分散システムへの移行例
この例では6つあるサービスのうち、レポートドメインのみを分散システムとして移行している。
備考
title:分散システムへの移行方法【リファクタリング入門6】
description:コンポーネントのドメインが名前空間によって明確に分けられてる場合、そのコンポーネントの分離をサービスレベルにまで分離し、サービスベースアーキテクチャを構成する。
img:https://github.com/kawadasatoshi/techblog/blob/main/0/inhouse_se/3063/breakdown.png?raw=true
category_script:page_name.startswith("3")
