2

私はhttp://highscalability.com/の大ファンです。現在の開発では、サーバー側、特にデータベース層をスケールアウトできるようにするためのルートとして、機能境界に沿ってアプリケーションを分解することを検討しています。これには、アプリケーションのさまざまな機能コンポーネント (顧客が使用できるいくつかの個別のモジュールがあります) をサーバー上の独自の独立したアプリケーションとして実装することが含まれます。サーバーに接続するクライアントは、さまざまなデータのために接続する必要がある個別のサービスを認識しています統一されたビューがユーザーに表示されます。問題は、異なるコンポーネント内のデータ間にリンクがある場合に発生します。つまり、1 つのコンポーネントがすべてのユーザー データを保持しているが、別のコンポーネントがデータの一部の所有者としてユーザーを参照する必要がある場合です。私' m 現在、リンクの各サイドの主キー情報を保持することでこれを行っています (それらがすべて単一のデータベースに存在する場合と同様)。ただし、このリンク テーブルは両方のコンポーネントに存在して、どちらの方向でもルックアップを実行できるようにする必要があります。 、つまり、「特定のユーザーが所有するものを取得する」と「この特定のものの所有者を取得する」は、それぞれ異なるコンポーネントを使用します。これに代わる方法は、リンク データをコンポーネントの 1 つだけに格納することですが、その場合、逆引き参照には 1 回ではなく 2 回の呼び出しが必要になります。

私の質問はこれです.これらのリンクテーブルの重複は、私が避けるべきある種のコードの臭いですか、それとも、このような機能ラインに沿ってアプリを分割するときの方法ですか?

4

2 に答える 2

4

機能分解は悪い設計戦略です。

関数分解を使用してキッチンブレンダーを構築しようとすることを考えてみてください。ホイップ、ミックス、かき混ぜ、ブレンドするには、4 つのボウル、4 つのモーター、4 つのブレード、4 つのスイッチ、4 つの電源、および各「機能」を保持するための 4 つのベースが必要です。

機能分解は、要件の分析用です。設計のためではありません。

分析パスの後、共通コンポーネント、共通フレームワーク要素、および共通データ モデルを組み立てるために合成パスを実行する必要があります。複数の機能をサポートする単一のデータ モデルを使用する必要があります。

于 2008-10-30T13:14:19.690 に答える
1

それは状況次第だと思います-SOAは基本的に機能分解を意味するのではありませんか？

問題は、異なる機能が同じデータにアクセスする必要がある場合です。これはおそらく、何かがおかしい匂いです。おそらく、共通データへのアクセスを処理するために別の関数が必要であるか、この場合、関数分解が間違った答えである可能性があります。

キッチンを食品製造工場にスケールアップしようとしている場合は、ホイップ、攪拌、ブレンド用に別々のバットを用意し、バットが「サブスクライブ」するある種のパイプライン（または「バス」）を使用するのが理にかなっているかもしれませんが、ドーム型ブレンダーの場合、同じボウルを再利用し、アタッチメントを切り替え可能にする方が理にかなっています。

于 2008-11-04T12:53:48.960 に答える