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

re：アプリケーションアーキテクチャ、つまり、「組織が複合アプリケーションを作成するために使用している一連のアプリケーションが、スケーラブルで信頼性が高く、利用可能で管理しやすいことを保証する科学と技術」 組織内のさまざまなアプリケーションを見ると、アプリケーションをマージするさまざまな理由がわかりますが、それらを分離しておくことの良い理由も時々あります。 一般に、大きなシステムが少ない場合と小さなシステムが多い場合の長所と短所は何ですか（多くのシステムが情報を交換することを覚えておいてください）。 私は次のようなことを考えています：小さい、大きいアプリはアプリ間の配管が少ないことを意味しますが、小さいアプリが多いほど個々の部門の柔軟性が高くなります。 これに関する文献はありますか、または誰かが発見した長所と短所のリストを持っていますか？ 編集：私のシナリオでは、多くのアプリは社内で開発されたものではなく、既製のものでカスタマイズ可能ですが、より一般的なシナリオを自由に検討してください。

8 architecture  applications  enterprise-architecture 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 次のように、データがHashtable / Dictionary / Associative-Arrayのような構造で格納/交換されるコードを使用します { 'alpha': None, 'bravo': '', # 'charlie' is not given } どのフィールドが「指定」されているか、およびNone / Null / Nilまたは空の文字列として指定できる場合は、標準化はあまりありません。その結果、コードにはlike likeチェックif hasattr(obj, 'alpha')やデフォルトのフォールバックが散らばっています。 この種類の（imho）アンチパターンに名前や俗語はありますか？ 更新： まだ名前がないようですので、是非教えてください。現在、私たちはこれらを持っています： Incorporeal Horde（psrへのクレジット）

8 architecture  anti-patterns 

私の現在の開発状況では、多くのDLL、実行可能ファイル、静的ライブラリがあります。DLLに何を入れるかをどのように決定しますか？実行可能ファイルには何を入れるべきですか？異なる実行可能ファイルに別々の機能があるのはなぜですか？私は答えが簡潔になることを望んでいますが、これはそれが思われるだろう主に意見が分かれたトピックです。 大規模なプロジェクト（複数の実行可能ファイル）のどこに機能が存在するかをどのように決定しますか？「グッドデザイン」から「モジュール性」、「管理者が要件ドキュメントに入れるものは何でも」まで、さまざまな回答を期待しています。

8 design  architecture  libraries 

私はC ++で実装するシステムのアーキテクチャを設計しようとしていますが、人々が良いアプローチを考えたり、これまでに設計したアプローチを批評したりできるのではないかと考えていました。 まず、一般的な問題は画像処理パイプラインです。これにはいくつかの段階が含まれており、目標は高度にモジュール化されたソリューションを設計することです。これにより、任意の段階を簡単に入れ替えてカスタムコードに置き換えることができます（ユーザーが知っている場合は速度を上げることができます）。特定の段階が彼または彼女の問題において特定の方法で制約されていること）。 現在の考え方は次のようなものです： struct output; /*Contains the output values from the pipeline.*/ class input_routines{ public: virtual foo stage1(...){...} virtual bar stage2(...){...} virtual qux stage3(...){...} ... } output pipeline(input_routines stages); これにより、人々はinput_routinesをサブクラス化し、必要なステージをオーバーライドできます。とは言っても、私は以前このようなシステムで働いたことがあり、サブクラス化やデフォルトのものが面倒になりがちで使いにくいことがわかったので、自分で書くのはめまいがしません。また、さまざまなステージ（6または7がある）がデフォルトのテンプレートパラメーターになる、よりSTL的なアプローチについても考えていました。 誰もが上記のパターンの批評、テンプレートアプローチに関する考え、または頭に浮かぶ他のアーキテクチャを提供できますか？

8 design-patterns  architecture 

私たちの会社が管理しているソフトウェアの新しいリリースに備えて、私はスケーラビリティの問題を解決するための本当に良いアプローチであると私が信じるものに取り組んできました。私は、紙面上のデザインが実際に私が望んでいることを検証するために、概念実証をまとめるつもりです。チームに説明すると、上司は反対の提案をしました。これは、問題のある領域を説明する方法に一部影響を受けています。上司はまた、代替案を評価するために2つの概念実証を行うという私の提案を受け入れました。 それでは、概念実証のシュートアウトを実行するための最良の方法は何ですか？ソリューションの評価に使用している客観的基準と主観的基準の両方があります。リンゴとこれらのかなり異なるアプローチのリンゴを比較していることを確認したいと思います。 スループットとサイズに関する要件があります。つまり、1秒あたり特定の数のオブジェクトを処理し、そのレートを1時間維持する必要があることがわかります。 スケーラビリティを評価する必要があります（コアを追加したり、オブジェクトの数を増やしたりして） 開発のしやすさ（主観的）を評価する必要がある アルゴリズムを理解するのがいかに簡単かを評価する必要があります（主観的） 私は物事がどのように傾くかについて私の理論を持っていますが、それが私の結果に影響を与えたくありません。このプロセスで客観性を維持する方法に関するあらゆる意見、および私が検討する必要があるかもしれないことは、大いに感謝されます。

8 design  architecture  algorithms  evaluation 

概要としての短い要約： 私たちは小さなJava Web開発チームであり、JSF、Hibernate、Seamなどのさまざまなフレームワークとライブラリを使用してアプリケーションを作成し、それらすべてを一緒にJBoss ASにデプロイします。 当初、アプリは組み立てられ、いくつかの機能が追加されて潜在顧客に表示するショーケースが形成されました。研磨が行われ、アプリがリリースされ、承認されて機能し、時間が経つにつれ、追加機能が追加され、バグが修正され、新しいバグが発生しています。 高いバス要因とスタートアップレースのために、開発は手に負えなくなりました。システムのコアアーキテクチャを完全に理解していないのに、ますます多くの機能が追加されました。それはまだ機能していますが、システムが元の場所から別の場所に進化したため、常に落とし穴があり、最初はさまざまなショートカットが開発をスピードアップするために行われました-回避策が使用されているため、これはすべて戻ってきて開発が遅くなりますプロジェクトに新しい開発者を紹介するのはかなり難しい。 今、私は物事の整理と整理を進めています-バグ追跡システムのインストール、テスト/品質の文化の構築、自動テストの実行方法の検討、コードレビュー（私たちが欠けていたすべての豪華な専門的なもの）はじめに）クラスの階層や関数を整理するなどの一般的なリファクタリングを行い、ものを使いやすくします。これですべてが少し良くなりますが、やるべきことはまだたくさんあります。私は最初にシステムを構築した人ではなく（以前のプログラマーは去りました）、それを経験していません（現在2.5年間開発していますが、これが今のところ私の唯一の「オープンワールド」の経験です）。行う。 これが私の問題です： リファクタリングは常に良いものであり、私は物事を簡単にするために常にそれを行っていますが、基本的なアーキテクチャ（つまり、システムが依存するライブラリ、アプリケーションサーバー、データベースなど）をいつ、どのように、なぜアップグレードする必要があるのか​​、というのは私を困惑させます。 例： 現在、JBoss 4.2.2を使用しています。JBoss7.1のどこかをすでに読んでいますが、それでもいいですか？これをどのように評価できますか？ 大きなブロッカーのように見えるSeam 2.2を使用します（より高いJBossバージョンでは機能せず、JSF2をサポートしていません）。さらに、Seamの代わりにJEE機能を使用するように指示するソースが表示されます。 基本的に、私は上記の例で述べたものだけでなく、この問題の一般的なアプローチに興味があります-別のシステムの別のライブラリの別の時間にこの問題に遭遇する可能性があります（または他の誰かが同様の問題に直面する可能性があります） 。 だから、ポイントは何ですか？私は最新の状態で最先端のライブラリのみを使用する必要がありますか、それとも私が持っているものを使い続けるべきですか？私が使用している技術は文字通り死んだ馬であり、飛び降りることをどのように認識しますか？このようなテクノロジーのアップグレードはどのくらいの頻度で表示されますか？ そして、一般的な「アップグレード方法」の横にある別の質問。私のソフトウェアが「専門家によって作成された」ものと呼ばれる可能性があることをどのように認識しますか？一般的なプログラマーのセンス以外に、よくできたソフトウェアのJoelテストはありますか？

8 java  project-management  architecture  development-process  java-ee 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 イベントソーシングは、速度、パフォーマンスのスケーラビリティ、透過的な永続性、透過的なライブミラーリングを提供する手段としてLMAXによって普及しました。イベントソーシングと改名される前は、このタイプのアーキテクチャパターンはシステム普及率と呼ばれていましたが、LMAXチームが公開されるまでは、このパターンに慣れていませんでした。 このパターンは多数の本番システムで証明されていますか？したがって、保守的な個人でさえ、このパターンを受け入れる力があると感じる必要がありますか、それともイベントソーシング/システムの普及は、恐れを知らない人のために残されたエキゾチックなパターンですか？

8 java  architecture  performance  management  event-sourcing 

私は感情分析の初心者で、ベイジアンオピニオンマイニングのための優れたリソースと、それを自己改善させる方法を見つけました。しかし、最適な分析が提供されたデータセットに依存しているかどうか、そして自己改善は既知のパターンをデータセットに追加することになるので（私の理解）、アプリケーションがやがて巨大なデータセットで過負荷にならないのではないかと思っていました。より多くのパターンが毎日データセットに追加される時間ですか？アプリケーションをスケーラブルにするための適切なアプローチは何ですか（適切な場所で適切な用語を使用している場合）。

8 architecture  programming-practices 

本質的にXML文字列としてデータベースに保存されるオンラインドキュメントがあります。 ユーザーのためにドキュメントのバージョン管理を実装する方法を考えています。そのユーザーはドキュメントの以前のバージョンに戻ることができます。 更新私の場合、何十万ものユーザーがいるWebアプリケーションです。ユーザーは無制限のドキュメントを保存できます。ドキュメントのXMLは、MySQLのBlobフィールドに格納されるため、小さくはありません。結局、私はどういうわけか限界を制限する必要がありますが、それはすべて一緒に異なるトピックです。 これにアプローチする標準的な方法はありますか？バージョン間の違いのみを保存する必要がありますか？他に考慮すべきことは何ですか？

8 design  architecture  versioning 

エンタープライズアプリケーションを開発しようとしているが、アジャイルプロセスから理解できる限り、機能を小さなチャンクに分割し、それらを繰り返し開発します。データベースとアプリケーションのコアを最初に作成してから、これらを繰り返し拡張していました。 問題は、以前に使用していたことを維持する必要がありますか（コアを最初に開発する必要がありますか）、ストーリーの開発にコア開発を分配する必要がありますか？後で、私はコードが将来の拡張のために十分に柔軟であるかどうか確信がありません！ 何か案が？

8 architecture  agile  object-oriented-design 

私は、データベースからデータをフェッチし、UIに表示し、ユーザー入力を取り込んでデータベースに書き戻すことを主な目的とするWebベースのアプリケーションを開発しています。アプリケーションは、産業用強度アルゴリズムの処理を実行することはありませんが、ピーク時に非常に多くのヒットを受け取り（後述）、1日を通して変化します。 レイヤーは、典型的なプレゼンテーション、ビジネス、データです。データ層はデータベースサーバーによって処理されます。ビジネス層には、tcp経由でデータベースサーバーにアクセスするためのDALコンポーネントが含まれます。これらの層を層に分ける必要がある選択は次のとおりです。 プレゼンテーション層とビジネス層は同じ層に保持できます。 単独で別の層にあるプレゼンテーション層と、別の層にあるビジネス層。 選択肢2の場合、ビジネスレイヤーは、httpまたはtcpを介してWCFサービスを使用してプレゼンテーションレイヤーからアクセスされます。 ビジネスレイヤーで重い処理が行われていることはないので、上記のオプション1に傾いています。同じ理由で、新しい階層を追加してもネットワーク遅延が発生するだけだと思います。ただし、スケールアップまたはスケールアウトする必要がある場合のスケーラビリティに関しては、どちらが良い方法ですか？このアプリケーションは、1時間あたり最大600万人のユーザーをサポートできる必要があります。各ユーザーセッションには妥当な量のデータがあり、ユーザーの設定やその他の詳細が保存されます。ページレベルのキャッシュも使用します。

8 architecture 

再利用できるように手直ししているJavaコードがかなりあります。問題は、プロジェクト固有の部分が多く、アプリケーションプロジェクトとコードベースプロジェクト間の結合のレベルが高くなることです。 抽象メソッドの使用を実装するクラスを使用して子クラスからリソースを取得する以下の状況と、インスタンス変数を宣言するだけの状況と比較してください。 抽象メソッド： public abstract class SuperBaseClass { public abstract int getNumberOne(); public abstract String getStringOne(); public abstract String getStringTwo(); public printStuff() { Log.i("IntAndTwoStrings", String.format("%i %s and %s", getNumberOne(), getStringOne(), getStringTwo())); } } public class ReusedAppClass extends SuperBaseClass { public int getNumberOne() { return 1; } public String getStringOne() { …

8 java  architecture  code-reuse  abstraction  abstract-class 

電気信号の領域から脱出し、ソフトウェアを処理しているときに、定期的なポーリングが行われない「プッシュ」アーキテクチャのようなものは本当にありますか？ あるレベルでポーリングしていないデザインは考えられません。それは常に、あなたが扱っている実際の抽象化/ APIの1レベルか2レベル下にあるようです。ほとんどの「プッシュ」接続の受信側のソケットは、着信要求などをポーリングするだけです。

8 networking  architecture  push 

多くのスレーブエンティティで構成されるマスターと呼ばれるエンティティがあります。 データベースに存在できるマスターは1つだけであり、リポジトリーを照会して、指定されたIDのスレーブを取得します。 最初にSlaveRepositoryを作成し、それをIDでクエリしました。それは問題なく機能し、他の開発者が私のリポジトリを使用できます。 次に、集約ルートについて考え、MasterRepositoryを作成してマスターを返し、それに対してループを実行して、必要なスレーブエンティティを取得しました。私がここで感じた問題は、これを他の開発者に公開すると、同じようにする必要があるため、GetSlaveByID（string id）と呼ばれるMasterRepositoryのメソッドを使用して、スレーブを直接取得できます（ループ機能を非表示にします） ）。 さて、私のリポジトリはMasterRepositoryと呼ばれていてもスレーブを返す必要がありますか？そしてもっと重要なのは、どちらが正しい道なのか？ 私はDDDとTDDを適用しようとする初期段階にあるので、どちらが正しい方法であるかを判断する前に、おそらく多くのことを検討する必要があります。

8 architecture  tdd  domain-driven-design 

この質問はかなり主観的なようですので、ここに投稿します。 あなたはASP.NET MVCを使用してStackOverflowの独自のバージョンを書いているとしましょう、そうのようなクラスがありQuestion、Answer、User、などあなたがしている怠惰な、あなたはエンティティフレームワークを使用することにしましたのでは。したがって、上記のすべてのクラスにはナビゲーションプロパティがあります。QuestionそのAnswersをAnswer知っている、User投稿者を知っているなどです。 Martin Fowlerの本をたくさん読んだことがあるので、すべてのビジネスロジックを実装するためのサービスレイヤーが必ずあるはずです。ASP.NET MVCは、UIおよびアプリケーションロジック関連の機能にのみ使用します。 2つの質問があります。 あなたは直接のオブジェクト公開しますQuestion、Answerコントローラーにして他の人を？ ビューに対しても同じことをしますか？ 私は基本的に自分のアプリケーションにREST APIを提供するつもりもありませんし、「ちょっと、MY VIEWはそれが何であるQuestionかを知っているので、それが悪いかどうかわかりません。気に入らない！」 Questionクラスに次のようなフィールドがTimePostedあり、PostNewQuestionビューをそのクラスにバインドする場合に特に興味があります。そのフィールドをページ上のどのコントロールにもバインドしない場合は、投稿されないのでnull、コントローラー側でオブジェクトを取得したときにそのフィールドを設定します。それは大丈夫ですか、それとも悪い考えですか？私が考えている2つの反対のアプローチは、「どこでもDTO / ViewModelを使用すること」と「wtf、クラスが少ないほど常に良いことです！」です。 正しいアプローチは何だと思いますか？（私は直接的な答えがないことを知っているので、問題は「DTO / ViewModels /その他のアプリのアーキテクチャに適しているかどうかを判断するために何を検討すべきか」です。） また、Stackoverflowの非常に簡略化されたクローンを検討していることにも注意してください。 これはWebのみのプロジェクトです（REST APIなどは公開しません）。 ユーザー、質問、回答、タグ、検索機能があります（優れたビジネスロジックはありません） 1日あたり100人ほどのアクティブユーザーがいます（特別なパフォーマンス要件はありません） 新しいメンバーが開発チームに加わった場合でも、コードは読みやすく、驚きや特別な関心のある場所があってはなりません。 最初の3つのポイントが変更された場合の考えを表明することもできます-「顧客は、10000人の同時ユーザーを許可するために私たちのサービスを望んでいる」または「すべてのユーザーが15分に1回だけ投稿できるようにする必要がある」など。 ありがとう！

8 design  architecture  asp.net-mvc  entity-framework