タグ付けされた質問 「architecture」

Client application-> Front-end API cloud server->のような3層システム用のREST APIを設計していますuser's home API server (Home)。 Homeはホームデバイスであり、Front-endWebsocketまたは長い投票（これは、RESTに違反している最初の場所です。後でさらに悪化します）を介した接続を維持することになっています。Front-endほとんどの場合、Client要求をHome接続にトンネルし、一部の呼び出し自体を処理します。にHome通知を送信することがありますClient。 Front-endHome基本的に同じAPI を持っています。LAN経由で直接Client接続している可能性がありますHome。この場合、それ自体にHomeいくつかのClientアクションを登録する必要がありFront-endます。 このシステムでのRESTの長所は次のとおりです。 RESTは人間が読める形式です。 RESTには、動詞（CRUDなど）、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。 HTTP上で動作し、可能なすべてのプロキシを渡します。 RESTコントラは次のとおりです。 リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。必要な接続が壊れていて、あるはずだったことを知るためだけに、非同期呼び出しにFront-end戻る場合があります。202 AcceptedHome503 Homeにメッセージを送信する必要がありますClient。ClientポーリングするFront-endか、接続を維持する必要があります。 我々は考えているWAMP / アウトバーンを、それがすでにメッセージキューのように見ていることを私を襲ったとき、機能をパブリッシュ/サブスクライブを取得するのWebSocketの上に。 一種のメッセージングキューをトランスポートとして評価する価値はありますか？ メッセージキューの逆のように見えます： CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか？ これらの考慮事項はどのくらい深刻ですか？

9 architecture  web-services  rest  message-queue  websockets 

Zend Framework 1とDoctrine2をORMレイヤーとして使用して、PHPでアプリケーションを構築しています。すべて順調です。さて、私はたまたまZF1とDoctrine2の両方が独自のキャッシング実装に付属していて、それに依存していることに気付きました。私は両方を評価しましたが、それぞれに独自の長所と短所がありますが、どちらも私の単純なニーズに対して他のものより優れているとは言えません。どちらのライブラリも、実装ではなく、それぞれのインターフェイスに対して作成されているようです。 これが問題であると感じる理由は、アプリケーションのブートストラップ中に、2つのキャッシュドライバーを構成する必要があることです。それぞれに独自の構文があります。この方法でミスマッチが簡単に作成され、このため、キャッシュバックエンドへの2つの接続を設定するのは非効率的です。 今後の最善の方法を決定するつもりであり、あなたが提供できるかもしれないあらゆる洞察を歓迎します。 これまでに考えたのは、4つのオプションです。 何もせず、キャッシング機能を提供する2つのクラスが存在することを受け入れます。 ZendのインターフェースをDoctrineのキャッシング実装に固定するFacadeクラスを作成します。 オプション2、その逆-Fendを作成して、DoctrineのインターフェースをZend Frameworkバックエンドにマッピングします。 multiple-interface-inheritanceを使用して、すべてをルール化する1つのインターフェースを作成し、重複がないことを祈ります（つまり、両方に「save」メソッドがある場合、PHPのために同じ順序でパラメーターを受け入れる必要があります。適切な多型の欠如）。 どのオプションが最適ですか、または「上記のどれにも当てはまらない」のバリエーションがありません。

9 php  architecture  third-party-libraries  polymorphism 

VB4を学び、ボタンをフォームにドラッグし、そのボタンをダブルクリックし、魔法のように恵まれたイベントハンドラーにコードを入力したことを覚えています。QBASICから来た私は、「VB」の「V」に興奮しました。ビジュアルデザイナーは、スライスされたパン以来、文字通り最高のものでした。 もちろん、これらすべてをプログラムで行うことはできますが、「V」の魔法は非常に魅力的で、ボタンをドラッグせざるを得ませんでした。私たちはその道を進むように勧められました。 しかし、それから数年前、私はC＃と.netフレームワークについて学び始め、自分が知っていると思っていたすべてのものが窓から出て行ったばかりの方法に魅了されました。VB6には、.netで完全に明らかにされた多くの魔法がありInitializeComponentsます。たとえば、コンストラクターとメソッドを見てみましょう。後者では、ツールボックスからドラッグしたすべてのコントロールインスタンス、登録したすべてのイベント、およびデザイナーで設定したプロパティが見つかります。 そして、それは結構です...私は推測します。ただ、私は何が起こっているのかを "所有"していないように感じます。このコードは、デザイナーを介してのみ変更でき、煩わしいことに煩わされます。「OK」と書かれたボタンをあるフォームから別のフォームにコピーするたびに（その兄弟の「キャンセル」とともに）、実際にコードを複製しているのは間違いです。教皇は言っています。 宗教と思想学派はさておき、すべての客観性において、代わりに基本フォームからフォームを派生させて、[OK]ボタン（およびそのすべての友達）を基本フォーム上に置くべきではありませんか？FormBaseから派生するのようなものDialogFormBase。すべてのクラスはすぐに作成されます...コードを入力してください。ボタンは、クラスがどのようにインスタンス化されるかに応じて作成されます（つまり、コンストラクタ列挙引数がどのボタンを作成するかを決定します）、コントロールは、分割パネルとフローレイアウトパネルの配置内にレイアウトされ、次のようにフォームに注入されますContentメインコンテンツパネルに収まります。これは、ASP.netがマスターページとコンテンツプレースホルダーで行うことではありませんか？新しい「マスターページ」が必要になったときにフォームを派生させますが、この新しい「マスターページ」は依然としてベースフォームクラスから派生しているため、アプリケーション全体でビジュアルが一貫しています。 私にとっては、WinFormsのデザイナでこれまでに行った他のどのコードよりもはるかに多くのコードの再利用であり、難しくもありませんでした。また、自分で制御できない200行のメソッドがコードに散らばっていません。私が好きな場所にコメントを付けてください。デザイナーによって上書きされることはありません。：私はそれだけでこのリンクを私にもたらしたものですパターンとアーキテクチャの問題、だと思う共通の機能を共有するWindowsフォームのベストデザイン私は除いて、上のスポットに気づいた、そこに答えは、私は正確に何を示唆しています実行しますが、デザイナーの考慮事項のため、フォームの継承はお勧めしません。それは私が得ない部分です。コード構造の考慮事項のため、特にフォームとコントロールの継承に関しては、デザイナーを壊す以外に避けるべき理由はないと思います。 私たちはすべて怠惰になることはできないので、どの部分が欠けていますか？

9 architecture  winforms  designer 

ドメインドリブンデザインのプレゼンテーションレイヤーとアプリケーションレイヤーの間に明確な線を引くことができません。 コントローラ、ビュー、レイアウト、JavaScript、CSSファイルはどこに配置すればよいですか？ アプリケーション層かプレゼンテーション層か？ そして、それらが同じレイヤーですべて一緒に行く場合、何が他のレイヤーを含みますか？空っぽですか？

9 architecture  domain-driven-design  layers 

私は最近、ソフトウェア開発のアジャイルプラクティスに興味を持ちました。それ以来、多くの記事で、これらのプラクティスにより全体的なコストを削減できることを指摘しました。 その背後にあるロジックは通常、次のようになります。要件が変更された場合、この変更を次のスプリントバックログに反映できます。これにより、新機能の設計と実装が時間的に近いため、コストの削減につながります。後で要件を変更する必要があるほど、その要件を満たすためにコストがかかるという有名なルールに従って、コストは下がります。 しかし、中規模から大規模のソフトウェアプロジェクトは複雑です。要件が突然変更されても、その要件を満たすためにシステムの他の部分に触れる必要がないわけではありません。多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。したがって、コスト削減の全体的な要点はここではなくなります。もちろん、新しい要件がシステムの新しい独立した部分を必要とする場合、それは問題ではなく、古いアーキテクチャが成長するだけなので、再考して再実装する必要はありません。 そしてその逆。ウォーターフォールを使用していて、新しい要件を導入する必要があることに突然気付いた場合は、デザインを変更できます。既存のアーキテクチャを変更する必要がある場合は、再設計します。それが本当にそれを台無しにせず、システムの新しい部分を導入するだけなら、あなたは行ってすべての仕事をします、ここでは問題ありません。 そうは言っても、アジャイル開発の唯一の利点は、スプリント間で機能を完全にビルドできることだけであるように思えます。多くの人やプロジェクトにとって、これは重要ではありません。さらに、アジャイルはソフトウェアアーキテクチャ全体で悪い結果を招くように見えます。機能が相互に平手打ちされるため、アジャイルチームは機能が機能するかどうかではなく機能が機能することのみを気にします。これは、システムが時間とともに複雑になると、アジャイル開発の実践により、製品アーキテクチャ全体の混乱が実際に増大し、最終的にコストが高くなります。なぜなら、ウォーターフォールにより、アーキテクチャを完成させることができるからです。あなたが何かを解放する前に。 明らかに、多くの人が実稼働環境でアジャイルを使用しているので、どこかで間違っているに違いありません。

9 project-management  architecture  agile 

Silverlightアプリケーションに取り組んでいます。私はそれをいくつかのアセンブリに分割しました： ドメイン リポジトリー（Sterlingデータベースに存続するものすべて） UI ... これは私が学んだ方法ですが、疑問に思いました。DLLが再利用されないことがわかっている場合、それらを分割する必要がありますか？または、すべてを1つのアセンブリに配置し、フォルダと名前空間を使用して整頓できますか？ アセンブリが多すぎるプロジェクトも見ました。適切な場所で名前空間を使用する代わりに。 それで、いつ新しいコードの一部に対して新しいアセンブリを作成するのですか？このテーマに関する良いリソースはありますか？また、コードを技術的に（ドメイン、データ、UIなど）に分割したり、機能的に（つまり、患者管理、患者医療、病院ロジスティクスなど）分割したりしますか？

9 .net  architecture  visual-studio  code-organization 

バックグラウンド ローカルデータベースには、約13億の一意の行が含まれています。各行は、特定の緯度と経度（場所）に間接的に関連付けられています。各行には日付スタンプがあります。 使用事例 問題は次のとおりです。 ユーザーは、開始/終了日と値の範囲（たとえば、100から105）を設定します。 システムは、特定の日付に一致するすべての行を、場所ごとにグループ化して収集します。 システムは、これらの日付の間に、指定された値の範囲に該当する可能性がある場所を決定します。 システムは、一致するすべての場所をユーザーに表示します。 これは速度と規模の問題です。 質問 そのようなシステムが5秒未満でユーザーの結果を取得できると想像できる最も安価なソリューションアーキテクチャは何ですか。 現在のシステム 現在の環境は次のとおりです。 PostgreSQL 8.4（アップグレードは可能です。データベースの切り替えはオプションではありません） RおよびPL / R XFS WD VelociRaptor 8 GB RAM（Corsair G.Skill; 1.3 GHz） クアッドコア本物のインテル7（2.8 GHz） Ubuntu 10.10 ハードウェアのアップグレードは許容されます。 更新-データベース構造 数十億行が次のようなテーブルにあります。 id | taken | location_id | category | value1 | value2 | value3 id-主キー 取られた-行に割り当てられた日付 location_id-緯度/経度への参照 …

9 architecture  database  geospatial 

技術的なアーキテクチャのトレードオフ分析手法（ATAM）や、よりビジネス指向の費用便益分析手法（CBAM）などのアーキテクチャ評価手法に精通しています。ただし、これらの方法はかなり大規模です。いくつかのブレーンストーミングセッション、プレゼンテーション、トレードオフを説明する多数のシナリオの開発などを規定します。特定のサイズのプロジェクトには役立ちますが、通常は内部プロジェクトやデスクトップアプリケーションには大きすぎます一握り（またはそれ以下）の開発者によって開発されましたが、それらは小さいですが、かなり急な品質制約（パフォーマンス、スケーラビリティ、適応性）を持っています。 過去に私が使用した典型的な方法は、1人の開発者（またはチームに1人いる場合はアーキテクト）にアプリケーションの一般的なアーキテクチャを考えさせ、それをチームの残りのメンバーとホワイトボードで話し合うことです。簡単に描画して理解できる疑似UML表記。これは通常、アーキテクチャーのフィードバックといくつかの反復につながります。しかし、それは少し非公式になりがちで、後で間違った決定になる可能性のあるあらゆる種類の仮定が行われる傾向があります。 ATAMような方法は、典型的には、誰もが、少なくともアーキテクチャは、正確に何に同意するまでの議論につながる、アーキテクチャについて深く考えるようにすべての利害関係者を強制的です。 軽量の先行アーキテクチャ評価を行った経験がある人はいますか？もしそうなら、良い習慣は何ですか？

9 architecture  evaluation 

「標準」の考え方はソフトウェアに広まっています。Canonical Model、Canonical Schema、Canonical Data Modelなどのパターンは、開発中に何度も登場するようです。 多くの開発者と同様に、私は頻繁に、批判的ではないが、正規モデルが必要であるという従来の知恵に従いました。それ以外の場合は、マッパーとトランスレーターの組み合わせの爆発に直面します。または、少なくとも、数年前にやや悪名高いEFの「自信なしの投票」を初めて読んだときまで、私はそれを行っていました。 正規データモデルの追求をかつて支持していたという仮説は、そのアイデアが実践されたときに発見されるであろう要因を含まず、含めることもできませんでした。長年の試行錯誤の結果、正規データモデルが使用される可能性のある個々のコンテキストに個別のモデルを使用することが、最も複雑なアプローチではなく、最もコストのかからないアプローチであり、保守性と拡張性の向上につながります。コンテキストモデルを使用したアプリケーションとエンドポイントの比較。これは、正規モデルが行うソフトウェアエントロピーを促進しないアプローチです。 エッセイはその主張を裏付けるいかなる種類の証拠も提示していませんが、代替案を試すのに十分長い間CDMアプローチに疑問を投げかけ、結果のソフトウェアは文字通りまたは比喩的に爆発しませんでした。しかし、それだけですべてが孤立しているわけではありません。運が良かっただけかもしれません。 ですから、ソフトウェアシステムまたはアーキテクチャに標準モデルとコンテキストモデルを組み合わせた場合の実際的な長期的な影響について、真剣な調査が行われたのでしょうか。 あるいは、それを尋ねるのが早すぎる場合は、開発者/アーキテクトに、CDMから独立したコンテキストモデルへの（またはその逆の）CDMから個人的なエクスペリエンスへの切り替えについて書いてもらい、生産性、複雑さ、信頼性などの実際的な影響は何でしたか？ 異なるレベルでの違いについてはどうでしょうか。つまり、単一のアプリケーションで同じモデルを使用する場合と、アプリケーションのシステムまたは企業全体で使用する場合の違いはどうでしょうか。 （事実のみ、お願いします。戦争の話は大歓迎ですが、憶測はありません。）

9 design-patterns  architecture  data  domain-model 

私たちのチームは当初、JavaScriptの専門知識が最小限のサーバー側開発者で構成されていました。ASP.NETでは、コードビハインドで、または最近ではMVCのコントローラーを介して多くのUIロジックを記述していました。 少し前に、2人の高レベルのクライアント側開発者がチームに加わりました。HTMl / CSS / Javascriptで、サーバー側のコードとサーバー側のWebコントロールを使用してこれまで実行できたことのほとんどすべてを実行できます。 コントロールの表示/非表示 検証を行う AJAX更新の制御 ：私はそれを考え始めので、多分ちょっとアマゾンフルフィルメントAPIのように、私たちのビジネスロジックの周りにハイレベルのAPIを作成する方が効率的でしょうhttp://docs.amazonwebservices.com/fws/latest/APIReference/、そのクライアントので、サイド開発者はUIを完全に引き継ぎ、サーバーサイド開発者はビジネスロジックのみに集中します。 したがって、注文システムでは、次のような高レベルのAPIを使用します。 OrderService.asmx CreateOrderResponse CreateOrder(CreateOrderRequest) AddOrderItem AddPayment - SubmitPayment - GetOrderByID FindOrdersByCriteria ... APIへのJSON / RESTアクセスがあるため、クライアント側のUIから簡単に利用できます。このAPIを使用して、内部UI開発とサードパーティが独自のアプリケーションを作成することもできます。 Javascriptの進歩と優れたクライアント側開発者の可用性により、コードビハインド/コントローラーを取り除き、クライアント側開発者が消費できる高レベルAPI（ala Amazon）の開発に集中するのは今が良い時期ですか？

9 javascript  architecture  asp.net  team  enterprise-architecture 

バックグラウンド 現在、MS Officeのプラグインのテストを自動化しています。私たちはVS 2010でコード化されたUIテストを作成しています。「コード化されたUIテストビルダー」ツールを使用できると思いますが、それは実際には私の特定のケースには適していません。 このため、さまざまなアクション機能を追加するUIコントロール/マップごとに、独自のUIマップクラスと拡張メソッドを作成しました。たとえば、ボタンを押すか、UI値をアサートします。 テストケースのシナリオはテストクラスにあります。 私はこの分野の新人であり、自動化テスターとして働くのも初めてです。 質問 プログラミング/設計の観点から、デスクトップアプリケーションのテスト自動化に関するいくつかの優れた実践についての経験とアドバイスを共有してくれる人は親切でしょうか？

9 programming-practices  testing  architecture 

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。 このアプリケーションでは、Authマイクロサービスが必要です。 また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。 これまでのところ、私は次のアイデアを持っています： 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。 これに関するアドバイスをいただければ幸いです。 ありがとう

9 design  architecture  microservices  authentication 

ここで説明するように、私はクリーンなアーキテクチャを使用してプロジェクトを構築しようとしています。Goでこれを行う方法についての素晴らしい記事を見つけました。 この例は非常に単純なものであり、作成者はコードをパッケージ内のレイヤーに基づいて名前が付けられたパッケージに入れます。ボブおじさんのアプリケーションのアーキテクチャはその意図を明確に伝えるべきだという考えが好きです。したがって、ドメイン領域に基づいたトップレベルのパッケージをアプリケーションに持たせたいのです。したがって、私のファイル構造は次のようになります。 /Customers /domain.go /interactor.go /interface.go /repository.go /... the same for other domain areas これの問題は、複数のレイヤーが同じパッケージを共有することです。したがって、依存関係のルールがいつ違反されているかは明確ではありません。何が何に依存しているかを示すインポートがないためです。 私は、これはあなたが個々のファイルをインポートすることができますので、問題の限りではありませんので、Pythonの背景から来ているcustomers.interactorインポートすることができcustomers.domain。 パッケージをネストすることにより、gOで同様のことを実現できます。その結果、customersパッケージにはドメインパッケージとインタラクターパッケージなどが含まれます。これは不格好に感じられ、同じ名前のパッケージは扱いが面倒です。 別のオプションは、ドメイン領域ごとに複数のパッケージを作成することです。1つはcustomer_domainと呼ばれ、もう1つはcustomer_interactorと呼ばれます。しかし、これも汚い感じがします。これはGoのパッケージ命名ガイドラインにうまく適合せず、名前には共通のプレフィックスが付いているため、これらの個別のパッケージはすべて何らかの方法でグループ化する必要があるように見えます。 では、これに適したファイルレイアウトは何でしょうか。

9 architecture  golang 

現在、会社で使用するアプリケーションを計画しています。デスクトップアプリケーションをビルドするために必要です。現在のところ、近い将来、アプリケーションがモバイルまたはブラウザーで利用可能になるかどうかは不明です。 私には2つの可能性があります。 デスクトップアプリケーションから直接データベースにアクセスする REST APIを作成してこれに接続する アプリケーションが社内のデスクトップアプリケーションのみである場合、REST APIを使用できますか？それが可能であることは知っていますが、「正しい」方法ですか？（ベストプラクティス） REST APIを直接作成することには、いくつかの（可能な）利点と欠点があります。 短所： 開発に時間がかかる より複雑 サーバーはより多くの作業を行います セキュリティ上の問題 もっとゆっくり？（サーバーとデスクトップアプリケーションは同じネットワーク上にあります） 利点： 他のプラットフォームへの移行は簡単です ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません 複雑さについても同じ セキュリティ（コメントでtkauslが言及） 保守性（WindRavenによるコメントでの言及）

9 architecture  rest  api  desktop-application 

私はおもちゃのプロジェクトとして小さなツールに取り組んでおり、2つのディレクトリの違いを示し、どのファイル/ディレクトリが追加、削除、変更されたかなどを示しています。 私はこれらの変更を、それがファイルであるかディレクトリであるかを区別せずに、単に「ChangeItem」オブジェクトとして表現しようとしていました。しかし、それらをツリーに表示する方法、子供の親が誰であるかを知る方法など、多くの問題が発生しました。また、非常に直感的ではありませんでした。 次に、ディレクトリの変更とファイルの変更の間で変更を分割します。これにより、コーディングが非常に簡単になり、何が起こっているのかを理解することが容易になりました。これで、ディレクトリ内のすべてのファイルを選択するなど、はるかに簡単になりました。 私の質問は、抽象化を使用するか、コードでより具体的にするかをどのようにして知ることができるかです。抽象化が多すぎるか少なすぎるかをどのように判断できますか？

9 self-improvement  design-patterns  architecture  code-quality  abstraction