このページの目的 コンポーネントのドメインが名前空間によって明確に分けられてる場合、そのコンポーネントの分離をサービスレベルにまで分離し、サービスベースアーキテクチャを構成する。 サービスベースアーキテクチャとは? サービスベースアーキテクチャのメリットとデメリット サービスベースアーキテクチャは、マイクロサービスアーキテクチャの要素もある、分散型のアーキテクチャだ。 しかし、マイクロサービスやイベント駆動のタイプに見受けられる複雑さやコストがなく、多くのビジネスアプリケーションで選択されている。 構成要素は3つ存在し 個別にビルドされたユーザーインターフェース 個別にビルドされたリモートのバ…
名前空間を整備する まず、モノシリックアプリケーションの分解では、その足掛かりとして目指すべきアーキテクチャはサービスベースアーキテクチャである。 コンポーネントドメインを作成することは、サービスベースアーキテクチャへの移行を手助けする。 コンポーネントドメインとは、名前空間の名前のことで物理的に表示される。 そして、コンポーネントを表すドメインは次の4つから構成されるべきだ。 アプリケーション.ドメイン.サブドメイン.コンポーネント.クラス 名前空間のサンプル例 例えば、次の様な条件があるとする アプリケーション:ss ドメイン:customer サブドメイン:billing コンポーネント…
モノシリックなアプリケーションを分散アーキテクチャに移行する際には次の3つの質問に答えられる様にしておく必要がある。 既存のアプリケーションは分解可能なのか? 必要なのはコードの書き直しなのか?それともリファクタリングなのか? 移行にかかる費用はどれくらいなのか? 例えば、CIOから次の様に質問が飛んで来るかもしれない 複雑なモノシリックアプリケーションをマイクロサービスにする移行作業にて、プロジェクトの初日CIOに次のことを尋ねられた。 「このプロジェクトの移行作業はゴルフボールサイズなのか?バスケットボールサイズなのか?旅客機サイズなのか?」 このときに、私はその質問に答えられなかったが、…
コンポーネントの継承のデメリット 例えば、次の二つの名前空間があるとする survey(クラス含む:アンケートの通知やアンケートの作成を行う) survey.templates(クラス含む:アンケートのテンプレートを含む) この二つは、明らかに親子関係が存在する。 また、開発者の立場からすれば、これらの親子関係は理にかなっている様に見える。 しかし、このようなコンポーネントの親子関係はいくつか問題を生む。 これらのコンポーネントは厳密に言えば独立しておらず、これらのコンポーネントから一つのサービスを作ろうとしても、templatesはsurveyサービスに入れるか、別のサービスとして独立させる…
ソースコードの再利用性を高める 前回までの内容 minegishirei.hatenablog.com 前回までの内容で、コンポーネントの機能を増減させて適切なサイズにウェイト調節しました。 今回は、共通のサービスを特定・統合することで、ソースコードの再利用性を高める。 ソースコードの再利用性を高める ソースコードの共通部分とは ソースコードの共通部分を発見する 共通部分発見方法1. 類似コードをVisual Studioで発見する 共通部分発見方法2.類似している名前空間を検出する 共通部品の抜き出しの注意事項 備考 ソースコードの共通部分とは 今回抜き出す「ドメインで共通するコンポーネント…
このサイトの目的:ソースコードのサイズと管理方法 モノシリックなアプリケーションを移行する際には、コンポーネントを特定し、サイズを図ることが最初の手順となる コンポーネントのサイズとは、コンポーネントが保有する機能の数のことである。 例えば、チケットの販売システムで購入ボタンに紐ずくイベントハンドラがSQLの発行を行うのは明らかにコンポーネントが担う役割の上を行っている。 その場合はイベントハンドラとDAOを別のコンポーネントとして分離しウェイトを減らさなければならない。 ここでのコンポーネントとは、Pythonであればディレクトリ構成による名前空間、C#でのnamespace呼び出しによる名…