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

インタビューで「Google検索をどのように実装しますか？」そのような質問にどう答えますか？Googleの一部の実装方法を説明するリソース（BigTable、MapReduce、PageRankなど）があるかもしれませんが、これはインタビューに完全には適合しません。 どのような全体的なアーキテクチャを使用しますか？また、これを15〜30分でどのように説明しますか？ 最初に、約1万件のドキュメントを処理する検索エンジンの構築方法の説明から始め、シャーディングを介して約5,000万ドキュメントに拡張し、その後、別のアーキテクチャ/技術的飛躍を実現します。 これは、20,000フィートのビューです。私が望んでいるのは詳細です-あなたがインタビューで実際にそれに答える方法です。どのデータ構造を使用しますか。アーキテクチャで構成されているサービス/マシン。典型的なクエリレイテンシはどうなりますか？フェイルオーバー/スプリットブレインの問題はどうですか？等...

44 design  algorithms  architecture  search 

クリーンアーキテクチャユースケースをさせインタラクタ応答/表示を処理するために（DIP以下、注入される）プレゼンタの実際の実装を呼び出すことを示唆しています。ただし、このアーキテクチャを実装し、インタラクターから出力データを返し、コントローラー（アダプター層内）がその処理方法を決定できるようにする人がいます。2番目のソリューションは、インタラクターへの入力ポートと出力ポートを明確に定義していないことに加えて、アプリケーションの責任をアプリケーション層から漏えいさせていますか？ 入出力ポート Clean Architectureの定義、特にコントローラー、ユースケースインタラクター、プレゼンター間の関係を説明する小さなフロー図を考慮すると、「ユースケースの出力ポート」がどうあるべきかを正しく理解しているかどうかはわかりません。 六角形アーキテクチャのようなクリーンアーキテクチャは、プライマリポート（メソッド）とセカンダリポート（アダプタによって実装されるインターフェイス）を区別します。通信フローに従って、「ユースケース入力ポート」がプライマリポート（したがって、単なるメソッド）になり、「ユースケース出力ポート」が実装されるインターフェイスになります。実際のアダプターを取得するコンストラクター引数、インタラクターが使用できるようにします。 コード例 コード例を作成するために、これはコントローラーコードになります。 Presenter presenter = new Presenter(); Repository repository = new Repository(); UseCase useCase = new UseCase(presenter, repository); useCase->doSomething(); プレゼンターインターフェイス： // Use Case Output Port interface Presenter { public void present(Data data); } 最後に、インタラクター自体： class UseCase { private Repository repository; private Presenter presenter; public UseCase(Repository …

42 architecture  architectural-patterns  onion-architecture 

リード開発者以外のアジャイル開発チームでは、一般的に： 標準を設定します（コーディングなど） チームの新技術を研究する チームの技術的な方向性を設定します 問題について最終決定権を持っています システムのアーキテクチャを設計します ただし、アジャイルチームの動作は異なります。 アジャイルチームは、前もってではなく、新しいデザインに依存します アジャイルチームは、1人が設計を指示するのではなく、一緒に設計します アジャイルチームは、プロジェクトを提供するのに最適な独自の技術的方向を決定します これにより、アジャイルチームの主任開発者はどこに残りますか？アジャイルチームにリード開発者を置くことは可能ですか？アジャイルチームはリードに異なる責任を要求しますか？

42 design  architecture  agile  scrum  team-leader 

私はジュニア開発者（経験3年以下）であり、仕事では新しいシステムを設計しています。私の主任開発者はプリンシパルアーキテクトになりますが、彼はシステムを自分で（並行して）設計しようと挑戦しました。 アイデアをブレインストーミングし、私がアーキテクチャの提案として見たものを提案するいくつかのイテレーションの過程で、私のリードは私がやっていることのほとんどが「設計」ではなく「設計」であるというフィードバックを私に与えました。 彼は、設​​計は実装の記述であるのに対し、アーキテクチャは実装に依存しないと説明しました。彼は、デザイナーの帽子を脱ぎ、建築家の帽子をかぶる必要があると言いました。彼は私にそうする方法について少しアドバイスをくれましたが、私もあなたに尋ねたいと思います： ソフトウェアデザイナーモードから抜け出し、アーキテクトのように考え始めるにはどうすればよいですか？ ここに、私が思いついた「デザイン」の例をいくつか示しますが、それは私のリードではアーキテクチャに関連するとは見なされませんでした。 私たちのシステムからリソースをロードおよびアンロードするためのアルゴリズムを思いつきました。私のリードは、アルゴリズムは明確にアーキテクチャではないと述べました。 システムが発生させる一連のイベントと、それらを発生させる順序を考え出しましたが、これもアーキテクチャとしてそれを削減するようには見えませんでした。 私は細部に巻き込まれ、十分に後退していないようです。アーキテクチャレベルの何かを思いついたとしても、さまざまな実装を試し、詳細をいじってから一般化して抽象化することで、そこにたどり着くことがよくありました。これをリードに説明したとき、彼は間違ったアプローチを取っていると言いました。「ボトムアップ」ではなく「トップダウン」を考える必要がありました。 以下に、プロジェクトに関する具体的な詳細を示します。 設計しているプロジェクトはWebアプリケーションです。 およそ10〜10万行のコードを見積もっています。 私たちは新興企業です。当社のエンジニアリングチームは約3〜5人です。 私たちのアプリケーションと比較できる最も近いものは、軽量のCMSです。同様の複雑さを持ち、主にコンポーネントのロードとアンロード、レイアウト管理、プラグインスタイルのモジュールを扱います。 アプリケーションはajax-yです。ユーザーはクライアントを一度ダウンロードしてから、サーバーに必要なデータを要求します。 MVCパターンを使用します。 アプリケーションには認証があります。 古いブラウザのサポートについてはあまり心配していません（なんと！）ので、私たちは世の中にあり、今後出てくる最新かつ最高のものを活用したいと考えています。（HTML5、CSS3、WebGL？、Media Source Extensionsなど） ここではいくつかあるプロジェクトの目標は： アプリケーションはスケーリングする必要があります。近い将来、私たちのユーザーは数百から数千のオーダーになりますが、数万から数百万以上を計画しています。 アプリケーションがいつまでも続くことを願っています。これは一時的な解決策ではありません。（実際には、私たちはすでに一時的な解決策を持っています。私たちが設計しているのは、私たちが持っているものの長期的な置き換えです）。 機密性の高い個人情報との接触がある可能性があるため、アプリケーションは安全でなければなりません。 アプリケーションは安定している必要があります。（理想的には、Gmailのレベルで安定しますが、火星探査機の極端にある必要はありません。）

42 design  architecture 

私は最近、一見些細な建築上の問題に直面しました。私のコードには、次のように呼ばれるシンプルなリポジトリがありました（コードはC＃です）： var user = /* create user somehow */; _userRepository.Add(user); /* do some other stuff*/ _userRepository.SaveChanges(); SaveChanges データベースへの変更をコミットするシンプルなラッパーでした： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); } その後、しばらくして、システムでユーザーが作成されるたびに電子メール通知を送信する新しいロジックを実装する必要がありました。システムへの呼び出し_userRepository.Add()とSaveChangesシステムの呼び出しが多数あったため、次のSaveChangesように更新することにしました。 void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); foreach (var newUser in dataContext.GetAddedUsers()) { _eventService.RaiseEvent(new UserCreatedEvent(newUser )) } …

40 architecture  single-responsibility  event 

RESTful APIの設計を進めています。特定のリソースに対してJSONとXMLを返したいことがわかっています。私はこのようなことをすると思っていました。 GET /api/something?param1=value1 Accept: application/xml (or application/json) ただし、次のように、誰かがこのために拡張機能を使用して投げ出しました： GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) これらのアプローチのトレードオフは何ですか？拡張機能が指定されていない場合はacceptヘッダーに依存するのが最善ですが、指定されている場合は拡張機能を優先しますか？そのアプローチには欠点がありますか？

40 architecture  web-services  rest  http 

私はもう2年近く大企業（8000人以上の従業員）で働いており、学習コースを終えた直後に採用されました。 ここの誰もが、しばしば非常にひどく設計されたハックに満ちたレガシーコードを毎日処理しなければなりません。最初は、物事をあまり批判しないように、目立たないようにしました。しかし、現状では、この状況に耐えることは非常に難しくなっており、私たちが使用するツールを改善/交換しようとする人は誰もいないようです。 より明確にするために： 廃止されたソース管理ツール（Visual SourceSafe） 完全な再構築のみをサポートするプレーンな古いメイクファイル .def すべての既存のアーキテクチャに対して手動で個別に維持する必要があるファイル モノリシックヘッダーファイルと非常に少数の異なるファイルを含むプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります） 「新しい」言語機能std::stringは使用しません（まあ、それほど新しいものではありませんが、私以外は使用していません） 数か月前に、新しいコンパイル環境を設計することで、それについて何かをすることにしました。インクリメンタルビルドを確実に動作させ、コンパイル時間を短縮し、構造化されたプロジェクトを改善し、.defファイルを自動生成することができました。さらに、GitとVisual SourceSafeの間のブリッジを作成しました。 いくつかの同僚や上司に自分の成果を見せましたが、誰も気にしないようでした。それらはすべて「まあ...人々は今それをそのようにするのに慣れています。なぜ私たちは物事を変えるのですか？」 私が提案した変更は、古いシステムから新しいシステムにソフトに移行できるように設計されたものです。それぞれの改善は個別に安全に適用できます。 同僚の何人かを変更に参加させようとさえしました。しかし、これまでのところ、成功していません。 あなたはすでに同様の状況に直面しましたか？「例によるリード」が機能しない場合、何ができますか？

40 architecture  productivity  changes 

開発中のアプリケーションのアーキテクチャパターンを調査しており、マイクロサービスアプローチが適切な選択のように思えますが、サービス間の相互作用を処理する方法はわかりません。 このアプリケーションは主に、ユーザー、ユーザーが所有するプロファイル、写真、および写真内の1つから多数のプロファイルを表すタグを扱います。ユーザーがアップロードした写真を返す方法、特定のタグ付きプロファイルを含む写真を返す方法などが考えられます。 これはマイクロサービスベースのアーキテクチャを設計する最初の試みであり、モノリシックなドメインモデルに触発された歴史から来ています。その世界では、コントローラーはこれらのドメインオブジェクトをつなぎ合わせますが、これがマイクロサービスの方法でどのように機能するかについて頭を包むのに苦労しています。

39 architecture  web-applications  domain-driven-design  microservices 

自明ではないアプリケーションを構築するとき、物事を迅速に機能させ、モデルロジックをビューと混合し、カプセル化を破るなどのコードのショートカットを取ることに集中するのが最善ですか？または、より多くのアーキテクチャを構築するために事前に時間をかけて、適切に構築する方が良いのですが、デザインが非常に流動的であり、フィードバックが原因でそれを捨てなければならない可能性があるため、この余分なコードはすべて使用されないリスクがあります別の方向に進むには？ コンテキストのために、デスクトップアプリケーションを構築しています。私は唯一の開発者であり、アルバイトをしているのでこのパートタイムで働いています。今、仕事のために、私は物事を正しい方法で行おうとしています。しかし、このプロジェクトは、人々からフィードバックを得ると変化すると予想されますが、それが正しいアプローチであるかどうかはわかりません。今週は数時間かけて、モデルの変更をビューに伝えるために、教科書のModel View Controllerの設計を導入しました。これは一般的に素晴らしいことですが、データを表示するために複数のビューが必要かどうかはわかりません。また、追加のアーキテクチャなしで物事をより迅速に表示できたことを知っています。プロジェクトに1週間に10〜15時間を費やすことになるので、優れたソフトウェアプラクティスに従えばデモできる何かを構築するには時間がかかると感じています。私はユーザーが ' 私がMVCを内部で使用していることに気をつけてください。彼らは問題を解決する何かが欲しいだけです。しかし、ショートカットの技術的負債が非常に大きいため、コードを維持したり、新しい機能を追加したりするのが非常に困難な状況にもあります。他の人がどのようにこの種の問題に取り組んでいるか聞いてみたいです。

38 design  architecture  quality 

私は、クラスの依存関係である文字通りすべてに（Spring）Dependency Injectionを使用するプロジェクトで働いています。Spring構成ファイルが約4000行に拡大した時点です。少し前、ボブおじさんの講演の1つをYouTubeで見ました（残念ながら、リンクが見つかりませんでした）。配布されます。 このアプローチの利点は、DIフレームワークをアプリケーションの大部分から切り離すことです。また、工場には以前の構成に含まれていたものがより多く含まれるため、Spring構成がよりクリーンになります。それどころか、これにより、多くのファクトリクラス間で作成ロジックが広がり、テストがより難しくなる可能性があります。 ですから、私の質問は、あなたが他のアプローチで見ている他の長所と短所です。ベストプラクティスはありますか？ご回答ありがとうございます！

38 architecture  dependency-injection 

ほとんどの場合、次のように、プロジェクトのルートディレクトリに開発アプリケーションの構成を保存します。 app |-- config.json しかし、この設定はバージョン管理システムに保存され、ユーザー名、パスワード、その他の機密情報が漏洩する可能性があるため、これは最善のアプローチではないようです。 12ファクターアプリガイドでは、構成ファイルをすべて削除し、構成セットアップに環境変数を使用することをお勧めします。 ...環境変数に設定を保存します。Env変数は、コードを変更せずにデプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコードリポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルやJavaシステムプロパティなどの他の構成メカニズムとは異なり、これらは言語およびOSに依存しない標準です。 それは本当にいいように思えますが、ソース変数にチェックインせずに、前述の環境変数をどこに保存しますか？そして、これらの変数をアプリに渡すためにどのツールを使用できますか？多数の設定オプションが存在する可能性があり、アプリを起動するたびに手動で入力するのは好ましくありません。したがって、それらはどこかの種類のファイルに保存する必要があります。したがって、このファイルはソース管理になり、元の場所に戻ります。 構成オプションを処理する一般的に受け入れられている方法はありますか。ソース管理にローカル構成を保存するリスクはありませんか？

38 architecture  configuration  configuration-management 

Microsoftのドキュメント、WikipediaのSOLIDプリンシペ記事、またはほとんどのITアーキテクトによると、各クラスに1つの責任のみを持たせる必要があります。誰もがこの規則に同意するように見える場合、誰もこの規則の理由について同意するように思われないので、私はその理由を知りたいです。 メンテナンスの改善を挙げている人もいれば、簡単なテストを提供したり、クラスをより堅牢にしたり、セキュリティを強化したりする人もいます。何が正しいのか、実際にはどういう意味ですか？なぜメンテナンスが改善され、テストが簡単になり、コードがより堅牢になるのですか？

37 design-patterns  architecture  solid  single-responsibility 

以前は、多くの抽象クラス/メソッドを作成していました。その後、インターフェイスの使用を開始しました。 現在、インターフェイスが抽象クラスを廃止していないかどうかはわかりません。 完全に抽象クラスが必要ですか？代わりにインターフェースを作成してください。いくつかの実装を含む抽象クラスが必要ですか？インターフェイスを作成し、クラスを作成します。クラスを継承し、インターフェイスを実装します。追加の利点は、一部のクラスが親クラスを必要とせず、インターフェイスを実装するだけであることです。 それでは、抽象クラス/メソッドは廃止されていますか？

37 object-oriented  architecture  inheritance  interfaces 

Webには、コードのにおいを参照し、リストするリソースが山ほどあります。しかし、建築の匂いに関する情報を見たことはありません。これはどこかで定義されていますか、利用可能なリストはありますか？アーキテクチャの欠陥、およびプロジェクトの速度、欠陥などへの影響について正式な調査が行われましたか？ 編集：私は本当に答えのリストを探していませんでしたが、アーキテクチャに関する臭い（ウェブ上または本）のドキュメントを探していました。

37 architecture  code-smell  quality 

何年も前に、私はオブジェクト指向ソフトウェア工学の修士号を取得しました。プロジェクトの開始、要件、分析、設計、アーキテクチャ、開発など、すべてをカバーしました。これまでの私のお気に入りのITブックは、オブジェクト指向ソフトウェアの開発、経験ベースのアプローチ（IBM-1996）でした。当時の真の専門家グループによって作成された本。オブジェクト指向の分析、設計、開発手法に対する作業成果物中心のアプローチについて説明しています。 私はデザインと開発を行い、ゲームのトップで満足していましたが、少し時代遅れに感じ始めました。アジャイルムーブメントはその日のファッションになり、新しいヒップワードでよく知られている反復的かつ漸進的なアプローチを再ブランド化しました。「要件」または「アーキテクチャ」と言ったとき、あたかもこれらのことが魔法に取って代わられたかのように、突然、経験の浅い開発者は眉をひそめ始めました。 設計と開発は楽しさを失い、私はIT業界全体を取り残そうとしていました。 それからScalaを発見しました。ああ、ほこりっぽい道の柔らかい雨のように。すべてが明確になり、空気が再び甘くなり、私のハードドライブの小さな光が夜中深く点滅し、私の発見の世界で私を楽しませてくれました。 システム設計が好きです。私はプログラマーというよりも、建築家です。分析、設計、思考、議論、改善が大好きです。シンプルでクリーンで鮮明なデザインが大好きです。 純粋なScalaソリューションをどのように設計しますか？ 確かに従来のシーケンス図、相互作用図、オブジェクト図などは、命令型と機能型のオブジェクト指向システムを融合させるために、すべて置き換えるか、改善することができます。確かに、まったく違うものの始まりがあります！ 肥大化した複雑さを探しているのではなく、柔軟なシンプルさを探しています。Scalaは実際はシンプルで簡単ですが（違いはありますが）、ヨガパンツのように要件に合わせて拡張できます。この素敵な言語には、簡単に始められ、要件やドメインに合わせて拡張できる設計システムが必要です。確かにUMLはそうではありません！ それでは、純粋なScalaシステムをどのように設計するのでしょうか？ちょっと想像してみてください。完全なシステムをゼロから設計する余裕があり、Scalaのみを使用することを知っています- モデルはどのように見えますか？構造と動作を説明するには、どのような種類の図が必要ですか？オプション、マッチ、ミックスイン、シングルトンオブジェクトなどを、新しくて軽量で革新的なツールセットではなく、既存のモデリングテクニックを拡張する複雑さに引き込まずに、どのようにモデリングしますか。 そのような設計/プロセス/ソリューションは存在しますか、それとも発明する時ですか？

35 scala  architecture