問題タブ [architecture]

さまざまな理由から、新しいビジネスオブジェクト/データストレージライブラリを作成しています。このレイヤーの要件の1つは、ビジネスルールのロジックと実際のデータストレージレイヤーを分離することです。

同じオブジェクトへのアクセスを実装する複数のデータストレージレイヤーを持つことができます。たとえば、ほとんどのオブジェクトを実装するメインの「データベース」データストレージソースと、ユーザーオブジェクトを実装する別の「ldap」ソースです。このシナリオでは、ユーザーはオプションでLDAPソースから取得できますが、機能がわずかに異なる場合があります（たとえば、ユーザーオブジェクトを保存/更新することはできません）が、それ以外の場合は、アプリケーションで同じように使用されます。別のデータストレージタイプは、Webサービスまたは外部データベースである可能性があります。

これを実装するために私たちが検討している主な方法は2つあり、私と同僚は基本的なレベルで意見が一致していません。どちらを使用するのが最適かについてアドバイスをお願いします。ここでいくつかの客観的な視点を探しているので、それぞれの説明をできるだけ中立に保つようにします。

• ビジネスオブジェクトは基本クラスであり、データストレージオブジェクトはビジネスオブジェクトを継承します。クライアントコードは、データストレージオブジェクトを処理します。

  この場合、共通のビジネスルールは各データストレージオブジェクトに継承され、クライアントコードによって直接使用されるのはデータストレージオブジェクトです。

  これは、クライアントコードが特定のオブジェクトに使用するデータストレージメソッドを決定することを意味します。これは、そのタイプのオブジェクトに対してインスタンスを明示的に宣言する必要があるためです。クライアントコードは、使用している各データストレージタイプの接続情報を明示的に知る必要があります。

  データストレージレイヤーが特定のオブジェクトに異なる機能を実装している場合、オブジェクトの外観が異なるため、クライアントコードはコンパイル時にそれを明示的に認識します。データの保存方法を変更した場合は、クライアントコードを更新する必要があります。

• ビジネスオブジェクトは、データストレージオブジェクトをカプセル化します。

  この場合、ビジネスオブジェクトはクライアントアプリケーションによって直接使用されます。クライアントアプリケーションは、基本接続情報をビジネスレイヤーに渡します。特定のオブジェクトが使用するデータストレージ方法の決定は、ビジネスオブジェクトコードによって行われます。接続情報は、構成ファイル（クライアントアプリは実際にはその詳細を認識/認識していません）から取得したデータのチャンクであり、データベースの単一の接続文字列、またはさまざまなデータストレージタイプの複数の接続文字列である可能性があります。追加のデータストレージ接続タイプは、別の場所から読み取ることもできます。たとえば、さまざまなWebサービスへのURLを指定するデータベースの構成テーブルです。

  ここでの利点は、新しいデータストレージメソッドが既存のオブジェクトに追加された場合、実行時に構成設定を設定して使用するメソッドを決定でき、クライアントアプリケーションに対して完全に透過的であることです。特定のオブジェクトのデータストレージ方法が変更された場合、クライアントアプリを変更する必要はありません。

• ビジネスオブジェクトは基本クラスであり、データソースオブジェクトはビジネスオブジェクトから継承します。クライアントコードは主に基本クラスを扱います。

  これは最初のメソッドに似ていますが、クライアントコードは基本ビジネスオブジェクトタイプの変数を宣言し、ビジネスオブジェクトのLoad（）/ Create（）/etc静的メソッドは適切なデータソースタイプのオブジェクトを返します。

  このソリューションのアーキテクチャは最初の方法と似ていますが、主な違いは、特定のビジネスオブジェクトに使用するデータストレージオブジェクトが、クライアントコードではなく、ビジネスレイヤーによって行われるかどうかの決定です。

この機能の一部を提供する既存のORMライブラリがすでに存在することは知っていますが、今のところそれらを割り引いてください（データストレージレイヤーがこれらのORMライブラリの1つで実装されている可能性があります）-また、意図的に言っていないことに注意してくださいここで使用されている言語は、強く入力されていること以外は何ですか。

ここでは、どの方法を使用するのが良いか（または他の方法を自由に提案するか）、およびその理由について、いくつかの一般的なアドバイスを探しています。

現在、私のチームで議論が行われており、他の見解に興味があります. さまざまな分析アルゴリズムとサービスを適用してドキュメントに注釈を付ける役割を持つ RESTful Web サービスがあるとします。基本的なやり取りは明確です。ドキュメント コレクションであるリソースがあります。クライアントは新しいドキュメントをコレクションに POST し、新しいドキュメントの URI を取得し、それを GET しdocURIてドキュメントを取得したり、GETして名前付きエンティティなどの{docURI}/metadata一般的なメタデータを表示したりできます。問題は、一部の分析が{docURI}/ne完了までに時間がかかる場合があります。UI で部分的な結果または増分結果を表示できるようにするため、分析が完了する前にクライアントがメタデータ URI を取得するとします。今後 GET を繰り返すと、より多くの結果が得られる可能性があります。

これまでに説明したソリューションには、次のものがあります。

• すべての分析が完了するまで HTTP 接続を開いたままにしておく (これはスケーラブルではないようです)
• content-lengthとヘッダーを使用 accept-range して増分コンテンツを取得します (ただし、最終的なコンテンツの長さは事前にわかりません)
• リソースごとに Atom フィードを提供して、クライアントが単にリソースを GET するのではなく、更新イベントをサブスクライブするようにする (アクティブなドキュメントが多数ある場合は、非常に複雑で、リソースを大量に消費する可能性があります)
• GET がその時点で利用可能なものを返すようにするだけです (ただし、最終的にいつ終了したかをクライアントが認識しているという問題は残ります) [コメントに続く冪等性への参照を削除するために編集] .

RESTful アーキテクチャで長期間または非同期の対話を処理するための代替方法について、意見や提案はありますか?

イアン

「レイヤー」と「ティア」の違いは何ですか？

MMORPG、バーチャル リアリティ サーバー、またはリッチ 3D クライアントを備えたその他のシステムのアーキテクチャについて説明している記事 / ブログへのリンクを提供してくれる人はいませんか。

事前にいくつかのコンテキスト：

200 人以上の開発者企業が、多かれ少なかれ独立したアーキテクチャ チーム/部門を最終的に立ち上げたと想像してみてください。20 以上の「プロジェクト」/本番環境のさまざまなサイズのアプリケーションで構成されるソフトウェア ポートフォリオは、プロジェクトの「アーキテクチャ」も担当するチーム リーダー/テクニカル リーダーによって処理されました。

アーキテクチャを統合および制御し、必要な知識交換に加えて、システム全体で特定の必要な大規模な再作業を可能にする必要性から、同社はアーキテクチャ部門を設立することを決定しました。

• そのような事業のすべきこととすべきでないことは何ですか?

• そのような建築チームを構成しているのは誰ですか?

• 彼らの責任は何ですか？

• 彼らの範囲外のものは何ですか？

• 会社にとって有用な移行戦略は何ですか?

• 誰かが「アーキテクチャ チーム」に言及するたびに、それらの皮肉な表情を防ぐにはどうすればよいでしょうか?

• あなたの会社は、そのような変化をすでに成功させていますか?
  なぜ失敗したのですか？
  なぜ成功したのですか？

これは、「アーキテクチャとは何か?」(これは非常に密接に関連しています ;) に関する議論であってはなりません。

本当に興味深い点は許容できる/現実的かもしれませんが、そのようなチームをインストールするための摩擦のない方法でさえあるかもしれません。

最後の質問の書き方がうまくいかず、ほとんどの回答は良かったのですが、質問の意図した方向性とはまったく異なっていたため、削除してこの質問として作り直しました。

私は自分のプロジェクトのソロ開発者であり、通常は非常に小さなことですが、FOSS プロジェクトにつながる可能性のあるアイデアがいくつかあります。ドキュメント (特定のプロジェクトやエンド ユーザーによって程度は異なります)、ソース管理、およびプロジェクト管理 (バグ追跡、時間管理などを含む) を信じています。ただし、正式なプロセスのどの程度に従うべきかはわかりません。

おそらく、README、関連する設計/要件ドキュメント、およびコード内コメントをソース管理下に置くだけで十分です。あるいは、1 人の開発者が従うのに適したアジャイル プロセスがあるかもしれません。あるいは、プロジェクトごとに昔ながらのウォーターフォール モデルを使用する必要があるかもしれません。

正式なプロセスが必要な場合でも、ソロ開発者向けにどのようなプロセスが存在するか、または採用することができますか?

編集: ドキュメントやソース管理のように、私が行っているタスクがあることを認識しています。ただし、質問の方法の部分についてはわかりません。個人の開発者として、よりアジャイルなアプローチを採用する必要がありますか (そうであれば、アジャイルのどの「ブランチ」 - XP? スクラム? RAD?) またはより従来のアプローチ (ウォーターフォールまたはスパイラル?) を採用する必要がありますか?

プロジェクト用のWebサイト(ASP.NET)といくつかのwinforms(.Net 2.0)(C#で記述)があります。ビジネス内で電子メールを送信するなど、両方が必要なタスクに web サービス (IIS6) を使用します。

私はWebサービスは素晴らしいと思いますが、あなたの経験から、 Webサービスにすべきこととすべきでないことを教えてください。

私は、クライアントのために SOA の土台を築くという任務を与えられました。目標は、エンドクライアントに依存しない方法でさまざまなプロセスを開放し、顧客を訪問する担当者などのためにデータをオフラインで利用できるようにすることです。

J2EE (Websphere) と Web サービスについて豊富な経験がありますが、そのような SOA を構築する方法についてアドバイスをいただければ幸いです。

落とし穴はどこにありますか？セキュリティはどうですか？サービスはどの程度細かくする必要がありますか? 等

チュートリアルやおすすめの書籍へのリンクも役立ちます。

ありがとう！

UMLコンポーネント図でアーキテクチャをモデル化する場合、コネクタのさまざまな属性を同時に表示するにはどうすればよいですか？好き

• ビジネスオブジェクト情報フロー（A-> B、B-> A、A <-> B）
• 要求/応答の方向
• 同期/非同期動作

シーケンス図のような他の種類の図を知っています。ただし、この情報をコンポーネント図に表示することには価値があります。

アソシエーション（単にコンポーネントが接続されていることを示す）または「ロリポップ」（要求/応答）を超えて何が可能ですか？

私はSOAについて読んでいるところですが、サービスレジストリ/UDDIについては定期的に言及されています。いい感じですが、実際にはどのように使われていますか？

• レジストリは、論理サービスをその物理的な実装（ポート、URLなど）から切り離すことを目的としていますか？
• レジストリは、遊ぶための興味深いサービスを探している人間が閲覧することを目的としていますか？
• アプリケーションを使用するサービスに配線するのは「間違っている」でしょうか？