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

マイクロサービスアーキテクチャ内でGraphQLを使用するのに最適な場所を理解しようとしています。 APIゲートウェイとして機能する1つのGraphQLスキーマのみを使用して、リクエストされたマイクロサービスにリクエストをプロキシし、そのレスポンスを強制することについては、いくつかの議論があります。マイクロサービスは依然として通信の考え方にREST / Thriftプロトコルを使用します。 代わりに、マイクロサービスごとに1つずつ、複数のGraphQLスキーマを使用する方法もあります。リクエストのすべての情報とGraphQLクエリを使用して、リクエストをターゲットのマイクロサービスにルーティングする小さなAPIゲートウェイサーバーを用意します。 最初のアプローチ 1つのGraphQLスキーマをAPIゲートウェイとして使用すると、マイクロサービスコントラクトの入出力を変更するたびに、それに応じてAPIゲートウェイ側でGraphQLスキーマを変更する必要があるという欠点があります。 2番目のアプローチ マイクロサービスごとに複数のGraphQLスキーマを使用する場合、GraphQLがスキーマ定義を適用し、コンシューマーはマイクロサービスから提供される入出力を尊重する必要があるため、ある意味で理にかなっています。 ご質問 GraphQLがマイクロサービスアーキテクチャの設計に適しているかどうか。 GraphQLを実装できるAPIゲートウェイをどのように設計しますか？

176 architecture  microservices  graphql 

データベースにレコードがあり、管理者と一般ユーザーの両方が更新を実行できるとします。 レコードを前のリビジョンにロールバックできるように、このテーブルのすべての変更をバージョン管理する方法について、良いアプローチ/アーキテクチャを誰かが提案できますか？

176 database-design  architecture 

「コルーチン」と「スレッド」の違いは何ですか？

174 architecture  multithreading  system  coroutine 

大規模なアプリケーションを（再）設計しています。DDDに基づく多層アーキテクチャを使用しています。 データレイヤー（リポジトリの実装）、ドメインレイヤー（ドメインモデルとインターフェイスの定義-リポジトリ、サービス、作業単位）、サービスレイヤー（サービスの実装）を備えたMVCがあります。これまでのところ、すべてのレイヤーでドメインモデル（主にエンティティ）を使用し、ビューモデルとしてのみDTOを使用しています（コントローラーでは、サービスはドメインモデルを返し、コントローラーはビューに渡されるビューモデルを作成します）。 DTOの使用、使用、マッピング、および受け渡しに関する無数の記事を読んだことがあります。明確な答えはないことを理解していますが、ドメインモデルをサービスからコントローラーに返すかどうかはわかりません。ドメインモデルを返しても、コントローラーは常にビュー固有のビューモデルを作成するため、ドメインモデルはビューに渡されません。この場合、正当なようです。一方、ドメインモデルがビジネスレイヤー（サービスレイヤー）を離れると、適切に感じられません。サービスはドメインで定義されていないデータオブジェクトを返す必要がある場合があります。その場合、マップされていないドメインに新しいオブジェクトを追加するか、POCOオブジェクトを作成する必要があります（一部のサービスはドメインモデルを返すため、これは醜いです。効果的にDTOを返します）。 問題は、ビューモデルを厳密に使用する場合、ドメインモデルをコントローラーに返すことは問題ありませんか、それとも、サービスレイヤーとの通信に常にDTOを使用する必要がありますか？その場合、必要なサービスに基づいてドメインモデルを調整しても問題ありませんか？（率直に言って、私はそうは思いません。サービスはドメインが持っているものを消費する必要があるからです。）厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？（私はそう思います。）DTOを使用する必要があることは明らかです（たとえば、サービスが多くのビジネスロジックを実行して新しいオブジェクトを作成する場合）。ドメインモデルのみを使用する必要がある場合もあります（たとえば、Membershipサービスが貧血のUser（ s）-ドメインモデルと同じDTOを作成することはあまり意味がないようです）-しかし、私は一貫性と優れた実践を好みます。 記事ドメインvs DTO vs ViewModel-それらをいつどのように使用するか？（および他のいくつかの記事）は私の問題と非常に似ていますが、この質問には答えません。記事EFのリポジトリパターンでDTOを実装する必要がありますか？も同様ですが、DDDは扱いません。 免責事項：存在していてファンシーであるためにデザインパターンを使用するつもりはありません。一方、アプリケーション全体の設計に役立ち、分離に役立つため、優れたデザインパターンとプラクティスを使用したいと思います。特定のパターンを使用するのは難しいとしても、少なくとも現時点では「必要」ではありません。 いつもありがとうございます。

174 asp.net-mvc  entity-framework  architecture  domain-driven-design 

ここで何が尋ねられているのかを知るのは難しい。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 7年前休業。 私はFacebookのアーキテクチャ、それらが取り組む課題と方法に関する記事や情報を探し求めてきました。彼らが使うものと彼らが使う理由。どのようにスケールするか、何をするための設計上の決定かなど。学習することの主な基盤。このような大量のトラフィックを処理するサイトについて知ることは、建築家などが新しいサイトを設計するときに特定のことを覚えておくための多くの指針を与えます。私が見つけたものを共有しています。 Facebook Science＆Social Graph（ビデオ） Facebookで拡張 Facebookチャットのアーキテクチャ Facebookブログ Facebook Cassandraのアーキテクチャとデザイン Facebookエンジニアリングノート Quora-Facebookアーキテクチャ 600Mユーザー向けFacebook FacebookでのHadoopとその使用法 ErlangのFacebook：チャットアーキテクチャ Facebookパフォーマンスキャッシュ Facebook Connectアーキテクチャ リンクが2つありますが、このサイトの制限により投稿できません。また、誰かがより良いものを持っている場合は共有してください（Facebookにのみ関連している必要はありません）。 PS-この調査を共有するのに適した場所を見つけることができなかったため、このイニシアチブになりました。これが誰かを助けることを願っています。

169 facebook  design-patterns  architecture 

CおよびC ++標準では、言語の実装の多くの側面が定義されたままであることを知っています。それは、他の特性を持つアーキテクチャがある場合、その標準に準拠するコンパイラを作成することが非常に困難または不可能だからです。 40年前は、どのコンピュータにも独自の仕様があったことを知っています。ただし、今日使用されているアーキテクチャについては知りません。 CHAR_BIT != 8 signed は2の補数ではありません（Javaでこれに問題があったと聞きました）。 浮動小数点はIEEE 754に準拠していません（編集：「IEEE 754バイナリエンコーディングではない」という意味です）。 私が尋ねている理由は、C ++が固定サイズの型などの他の低レベルの側面を義務付けないのは良いことだと人々によく説明するためです†。「他の言語」とは異なり、正しく使用するとコードが移植可能になるので良いです（編集：符号+大きさのアーキテクチャでの2の補数演算など、マシンの低レベルの側面のエミュレーションを必要とせずに、より多くのアーキテクチャに移植できるため） 。しかし、私は自分が特定のアーキテクチャを指すことができないのは残念です。 だから問題は：どのアーキテクチャが上記の特性を示すのか？ † uint*_tはオプションです。

154 c++  c  architecture 

私の開発作業で繰り返されるテーマは、社内プラグインアーキテクチャの使用または作成でした。構成ファイル（XML、.confなど）、継承フレームワーク、データベース情報、ライブラリなど、さまざまな方法でアプローチするのを見てきました。私の経験では： データベースは、構成情報を保存するのに最適な場所ではありません。特に、データが混在しています。 継承階層を使用してこれを試みるには、プラグインについての知識が必要です。つまり、プラグインアーキテクチャはそれほど動的ではありません。 構成ファイルは単純な情報を提供するのに適していますが、より複雑な動作を処理できません ライブラリはうまく機能しているようですが、一方向の依存関係は注意深く作成する必要があります。 私がこれまでに使用したさまざまなアーキテクチャーから学びたいと思っているので、コミュニティーに提案を求めています。SOLIDプラグインアーキテクチャをどのように実装しましたか？あなたの最悪の失敗は何でしたか（またはあなたが見た中で最悪の失敗）？新しいプラグインアーキテクチャを実装する場合はどうしますか？あなたが使用したどのSDKまたはオープンソースプロジェクトが、優れたアーキテクチャの最も良い例を持っていますか？ 私が自分で見つけたいくつかの例： Perlの依存関係注入のためのPerlのModule :: PlugableおよびIOC 依存関係注入のためのさまざまなSpringフレームワーク（Java、.NET、Python）。 SOの質問（含むJava用のリストとサービスプロバイダインタフェース） ドブス博士の記事を指すC ++ に関するSOの質問 SOの質問 ASP.NET MVCのための特定のプラグインの考え方について これらの例は、さまざまな言語の強みを発揮するようです。優れたプラグインアーキテクチャは、必ずしも言語に関連付けられていますか？ツールを使用してプラグインアーキテクチャを作成するのが最適ですか、それとも自分の次のモデルで作成するのが最適ですか？

154 plugins  architecture  language-agnostic  plugin-architecture 

AngularJSのリーダーであるIgor Minarによるこの投稿に関連して： MVP対MVVM対MVC。多くの開発者が何時間もの時間を費やして議論し、議論することができる、議論の余地のあるトピックです。 数年間AngularJSは（というか1そのクライアント側の変異体）に近いMVCとなりましたが、時間と多くのリファクタリングとAPIの改善のおかげ上で、それが近い今だMVVM - $スコープオブジェクトは、考えることができるのViewModelされていることControllerと呼ばれる関数で装飾されています。 フレームワークを分類してMV *バケットの1つに配置できることには、いくつかの利点があります。フレームワークを使用して構築されているアプリケーションを表すメンタルモデルを簡単に作成できるようにすることで、開発者がAPIに慣れるのに役立ちます。また、開発者が使用する用語の確立にも役立ちます。 とは言っても、開発者がMV *のナンセンスについて議論するのに時間を浪費するのではなく、開発者が適切に設計され、懸念の分離に従ってキックアスアプリを構築する方がいいと思います。このため、AngularJSをMVWフレームワーク-Model-View-Whateverとして宣言 します。「何でもあなたのために働く」の意味。 Angularは、ビジネスロジックやプレゼンテーション状態からプレゼンテーションロジックをうまく分離する多くの柔軟性を提供します。1日の終わりにそれほど重要ではないことについての白熱した議論ではなく、生産性とアプリケーションの保守性を向上させるために使用してください。 AngularJS MVW（Model-View-Whatever）設計パターンをクライアント側アプリケーションに実装するための推奨事項またはガイドラインはありますか？

147 javascript  angularjs  design-patterns  architecture  client-side 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 この質問を改善する JavaベースのWebアプリケーションアーキテクチャを共有しましょう！ Javaを使用して実装されるWebアプリケーションには、さまざまなアーキテクチャが数多くあります。この質問への回答は、さまざまなWebアプリケーション設計のライブラリとして役立ち、長所と短所があります。答えは主観的なものになると思いますが、できる限り客観的になるようにして、リストする長所と短所に動機を与えましょう。 アーキテクチャの説明に使用する詳細レベルを使用してください。答えが価値のあるものになるためには、少なくとも、あなたが説明するアーキテクチャで使用される主要なテクノロジーとアイデアを説明する必要があります。そして最後に重要なことですが、いつあなたのアーキテクチャを使うべきですか？ 始めます... アーキテクチャの概要 Java EE、Java Persistence API、サーブレット、Javaサーバーページなど、Sunのオープンスタンダードに基づく3層アーキテクチャを使用しています。 持続性 ビジネス プレゼンテーション レイヤー間の可能な通信フローは次のように表されます。 Persistence <-> Business <-> Presentation たとえば、プレゼンテーション層が永続化操作を呼び出したり実行したりすることはなく、常にビジネス層を通じて実行されます。このアーキテクチャは、高可用性Webアプリケーションの要求を満たすことを目的としています。 持続性 作成、読み取り、更新、削除（CRUD）の永続化操作を実行します。今回のケースでは（Java Persistence API）JPAを使用しており、現在、Hibernateを永続性プロバイダーとして使用し、そのEntityManagerを使用しています。 このレイヤーは複数のクラスに分割され、各クラスは特定のタイプのエンティティ（つまり、ショッピングカートに関連するエンティティが単一の永続クラスによって処理される場合があります）を扱い、1人のマネージャーだけが使用します。 また、この層はまた、格納JPAエンティティのようなものですAccount、ShoppingCartなど ビジネス Webアプリケーション機能に関連付けられているすべてのロジックは、このレイヤーにあります。この機能は、自分のクレジットカードを使用してオンラインで製品の支払いを希望する顧客の送金を開始する場合があります。新しいユーザーを作成したり、ユーザーを削除したり、Webベースのゲームでの戦闘の結果を計算したりすることもできます。 この層は、複数のクラスに分割され、これらのクラスの各々を用いて注釈さ@StatelessになるようにステートレスセッションBean（SLSB）。各SLSBはマネージャーと呼ばれ、たとえば、マネージャーはと呼ばれるように注釈が付けられたクラスである場合がありますAccountManager。 AccountManagerCRUD操作を実行する必要がある場合AccountManagerPersistence、永続化レイヤーのクラスであるのインスタンスを適切に呼び出します。の2つの方法の概略AccountManagerは次のようになります。 ... public void makeExpiredAccountsInactive() { AccountManagerPersistence amp = new AccountManagerPersistence(...) // Calls persistence layer List<Account> expiredAccounts = …

146 java  architecture  jakarta-ee 

私は自分のソーシャルネットワークを開発していますが、ユーザーのアクションのストリームの実装例をWeb上で見つけていません...たとえば、各ユーザーのアクションをフィルターする方法は？アクションイベントを保存する方法 アクションストリームとそのアクションにどのデータモデルとオブジェクトモデルを使用できますか？

140 design-patterns  architecture  stream  social-networking 

マイクロサービスアーキテクチャにまともな/安全な認証戦略を選択するのに苦労しています。このトピックで私が見つけた唯一のSO投稿はこれです：マイクロサービスアーキテクチャでのシングルサインオン ここでの私の考えは、各サービス（たとえば、認証、メッセージング、通知、プロファイルなど）で各ユーザーへの一意の参照（論理的には彼のuser_id）と、idログインした場合に現在のユーザーの固有の参照を取得することです。 私の研究から、2つの可能な戦略があることがわかります。 1.共有アーキテクチャ この戦略では、認証アプリは他のサービスの1つです。しかし、各サービスは変換を行うことができる必要がありますsession_id=> user_idしたがって、非常にシンプルでなければなりません。それが私がRedisを考えた理由です、それがkey：valueを保存するでしょうsession_id:user_id。 2.ファイアウォールアーキテクチャ この戦略では、認証アプリによってのみ処理されるため、セッションストレージはそれほど重要ではありません。その後、user_id他のサービスに転送できます。Rails + Devise（+ Redisまたはmem-cached、またはcookieストレージなど）について考えましたが、可能性はたくさんあります。重要なのは、Service Xがユーザーを認証する必要がないことです。 これらの2つのソリューションは、次の点でどのように比較されますか。 安心 堅牢性 スケーラビリティ 使いやすさ それとも、ここで言及していない別の解決策を提案するでしょうか？ 私はソリューション1の方が好きですが、私が正しい方向に進んでいるという事実で私を保護するデフォルトの実装をあまり見つけていません。 私の質問が閉じられないことを願っています。他にどこに質問すればいいのか本当にわからない。 前もって感謝します

138 authentication  architecture  microservices 

新しいスレッドの使用とスレッドプールのスレッドの使用の違いは何ですか？パフォーマンス上の利点は何ですか。また、明示的に作成したスレッドではなく、プールのスレッドの使用を検討する必要があるのはなぜですか。ここでは特に.NETについて考えていますが、一般的な例は問題ありません。

137 .net  multithreading  architecture  threadpool 

Fluxについて読んでいますが、Todoアプリの例は単純すぎて、いくつかの重要なポイントを理解できません。 ユーザープロフィールページを備えたFacebookのような単一ページのアプリを想像してみてください。各ユーザープロファイルページで、無限のスクロールでユーザー情報とその最後の投稿を表示します。ユーザープロファイル間を移動できます。 Fluxアーキテクチャーでは、これはどのようにストアとディスパッチャーに対応しますか？ PostStoreユーザーごとに1つ使用するのでしょうか、それとも何らかのグローバルストアを使用するのでしょうか。ディスパッチャーについてはどうですか？「ユーザーページ」ごとに新しいDispatcherを作成しますか、それともシングルトンを使用しますか？最後に、ルートの変更に応じて「ページ固有」ストアのライフサイクルを管理するのは、アーキテクチャのどの部分ですか。 さらに、単一の疑似ページには、同じタイプのデータの複数のリストがある場合があります。たとえば、プロフィールページで、フォロワーとフォローの両方を表示したいとします。UserStoreこの場合、シングルトンはどのように機能しますか？だろUserPageStore管理followedBy: UserStoreとfollows: UserStore？

132 javascript  facebook  architecture  reactjs  reactjs-flux 

ASP.NET MVCアプリケーションを開発しており、現在、リポジトリ/サービスクラスを構築しています。すべてのリポジトリが実装する汎用のIRepositoryインターフェイスを作成することには、各リポジトリが独自のインターフェイスとメソッドのセットを持っているのに対して、大きな利点があるのか​​と思います。 たとえば、汎用のIRepositoryインターフェイスは次のようになります（この回答から取得）。 public interface IRepository : IDisposable { T[] GetAll<T>(); T[] GetAll<T>(Expression<Func<T, bool>> filter); T GetSingle<T>(Expression<Func<T, bool>> filter); T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors); void Delete<T>(T entity); void Add<T>(T entity); int SaveChanges(); DbTransaction BeginTransaction(); } 各リポジトリはこのインターフェースを実装します、例えば： CustomerRepository：IRepository ProductRepository：IRepository 等 以前のプロジェクトで従った代替案は次のとおりです。 public interface IInvoiceRepository : IDisposable { EntityCollection<InvoiceEntity> GetAllInvoices(int …

132 asp.net  asp.net-mvc  architecture 

RESTfulなWebサービスについて学びます（CS修士課程プログラムの一部であるため、これを行う必要があると言ったほうがいいでしょう）。 私はウィキペディアでいくつかの情報を読んだり、Sun Developer NetworkでRESTに関する記事を読んだりしましたが、それは簡単な技術ではなく、RESTfulアプリを構築するための特別なフレームワークがあり、SOAP Webサービスやプログラマーは、SOAPをいつ使用し、RESTが優れたアプローチになる可能性があることを理解する必要があります。 数年前、SOAPは非常に人気があり（ファッショナブル？）、アイテム「SOAP」はすべての優れたCVに存在しなければならなかったことを覚えています。しかし実際には、それは非常にまれに使用され、非常に単純な目的を達成するために使用されました。 RESTはもう1つの「ファッションの最後の言葉」であるように見えます（または、RESTを実際に見たことがないので、私は完全に間違っている可能性があります）。 RESTを使用する必要があった理由と、RESTなしでは同じことができない理由（またはRESTなしで同じことを行うためにより多くの時間を費やす必要がある理由）をいくつか教えてください。 UPD：残念ながら、最初のコメントで私を驚かせるような具体的な議論はありません。RESTは素晴らしいテクノロジーだと私に思わせてください！ 私はこのような答えを見たいのですが： 私は別の複雑なHelloWorldアプリケーションを開発していて、大量の/小さなデータを転送する必要があるので、同僚にRESTソリューションを提案しました。 - くそっ！ジョニー、このアプリの実装には必ずRESTを使用する必要があります。–はい、ビリー。RESTを使用できますが、SOAPを使用する方が適切です。HelloWorldアプリケーションの開発について何か知っているので、私を信じてください。–しかし、SOAPは前世紀の昔ながらのテクノロジーであり、より優れたテクノロジーを使用できます。–ビリー、RESTを試すために3日間を費やす準備ができていますか？SOAPを使用すると、2時間でこれを実行できます。– はい、SOAPを使用して他の同じセキュリティ/パフォーマンス/ /スケーラビリティ/その他を実現するために、さらに多くの時間を費やすと確信しています。これからは、HelloWorldアプリケーションをRESTでのみ開発するべきだと私は確信しています。

123 web-services  rest  soap  architecture