タグ付けされた質問 「architectural-patterns」

私は多くのRobert C. Martinのコンテンツを読んだり見たりしています。私は、ソリッドステートドライブのためにSQLが不要であると言ってきました。これをバックアップするために他のソースを検索すると、ハードドライブとソリッドステートドライブのSQLパフォーマンスの違いを説明するランダムな記事がたくさんあります（これは関連していますが、研究しようとしているものではありません）。 最終的に、私は彼が何を得ようとしているのか理解できません。彼はSQLをNo-SQLテクノロジーに置き換えると言っていますか？彼はファイルシステムのファイルにデータを保存すると言っていますか？それとも、SQLi攻撃のために、人々にSQL /リレーショナルデータベースの使用をやめさせたいのでしょうか？彼がやろうとしているポイントを逃しているのではないかと心配しています。 あなたが彼の心から直接読むことができるように、ここにいくつかのリンクを提供します： ボビーテーブル クリーン建築レクチャー まず、SQLをシステムから完全に削除する必要があると述べています。 ソリューション。唯一の解決策。システムからSQLを完全に削除することです。SQLエンジンがない場合、SQLi攻撃はありません。 また、彼はSQLをAPIに置き換えることについて語っていますが、その前の引用と彼が記事の前半で述べていることから、SQLをAPIの背後に置くことを意味するとは思いません。 フレームワークは問題を処理しません; ... サイドノート：SQLと言って、Robertはほとんどのリレーショナルデータベースを意味すると確信しています。すべてではないかもしれませんが、ほとんどです。いずれにせよ、ほとんどの人はとにかくSQLを使用しています。そう... データの永続化にSQLが使用されていない場合、何を使用することになりますか？ それに答える前に、私も注意する必要があります。ロバートは、ソリッドステートドライブがデータの永続化に使用するツールを変更する必要があることを強調しています。SørenD.Ptæusの答えはこれを指摘しています。 また、「データ整合性」グループに対応する必要があります。さらなる調査の結果、ロバートは、datomicなどのトランザクションデータベースを使用する必要があると述べています。その後、CRUDはCR（作成および読み取り）に変わり、SQLトランザクションは完全になくなります。データの整合性はもちろん重要です。 このすべてを網羅する質問は見つかりません。私はロバートのガイドラインに一致する代替案を探していると思います。Datomicは1つですが、それですか？これらのガイドラインに適合する他のオプションは何ですか？また、ソリッドステートドライブで実際に機能しますか？

45 architecture  enterprise-architecture  architectural-patterns  plugin-architecture 

クリーンアーキテクチャユースケースをさせインタラクタ応答/表示を処理するために（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 

私のシナリオは次のとおりです。 さまざまな種類のセンサーからデータを受信し、後でさまざまなフロントエンドおよび分析サービスで使用できるように変換して保持するように設計されたシステムを設計しています。 私はすべてのサービスを可能な限り独立したものにしようとしていますが、問題があります。チームは、使用したいDTOを決定しました。外向きサービス（センサーデータ受信者）は、独自の方法でデータを受信し、JSONオブジェクト（DTO）に変換して、メッセージブローカーに送信します。メッセージのコンシューマーは、センサーデータメッセージの読み取り方法を正確に知ることができます。 問題は、いくつかの異なるサービスで同じDTOを使用していることです。更新プログラムは複数の場所に実装する必要があります。明らかに、ここでDTOのいくつかの余分なフィールドや不足しているフィールドを設計しました。サービスが更新されるまで問題はあまりありませんが、それでも私を悩ませ、気分が良くなります。間違いを犯す。簡単に頭痛になります。 システムを間違って設計しようとしていますか？そうでない場合、これを回避する方法は何ですか、または少なくとも私の心配を緩和するために？

33 architecture  microservices  architectural-patterns  dto  pubsub 

ソフトウェアに抽象化が多すぎて設計パターンが多すぎる、またはその逆を言うには、どうすればもっと多くの抽象化が必要かを知ることができますか？ 私が協力している開発者は、これらの点に関して異なる方法でプログラミングしています。 いくつかの小さな機能をすべて抽象化し、可能な限りデザインパターンを使用し、いかなるコストでも冗長性を回避します。 私を含む他の人は、より実用的であることを試み、すべての設計パターンに完全に適合するわけではありませんが、適用される抽象化が少ないため、理解がはるかに速いコードを記述します。 これはトレードオフであることを知っています。プロジェクトに十分な抽象化が行われていることをどのように確認できますか？ 例、Memcacheを使用して汎用キャッシングレイヤーを作成する場合。私たちは本当に必要ですかMemcache、MemcacheAdapter、MemcacheInterface、AbstractCache、CacheFactory、CacheConnector、...またはこれは、保守が容易とまだ良いコードは、これらのクラスの半分しか使用している場合ですか？ Twitterでこれを見つけました： （https://twitter.com/rawkode/status/875318003306565633）

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

ファイルをアップロードする関数であるAPIを作成しています。ファイルが正しくアップロードされた場合、この関数は何も/ voidを返さず、何らかの問題が発生したときに例外をスローします。 なぜ偽りではなく例外なのか？例外の内部で、失敗の理由（接続なし、ファイル名の欠落、パスワードの誤り、ファイルの説明の欠落など）を指定できるためです。カスタム例外を作成したかった（APIユーザーがすべてのエラーを処理するのに役立つ列挙型を使用）。 これは良い習慣ですか、それともオブジェクトを返す方が良いですか（内部にブール値、オプションのエラーメッセージ、エラーの列挙を含む）？

22 java  api-design  exceptions  functions  architectural-patterns 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 非同期のノンブロッキングイベント駆動プログラミングが大流行しているようです。これが何を意味するのか、基本的な概念を理解しています。しかし、私が確信していないのは、コードが非同期であることのメリットとなるタイミングと場所、またはブロッキングIOを非ブロッキングにする方法です。ライブラリを使用してこれを行うことができると確信していますが、より深い概念と、それを自分で実装するさまざまな方法にもっと興味があります。 このテーマに関する包括的な/決定的な書籍、または他のリソース（デザインパターンのGoF、CのK＆R、bashなどのtldpなど）はありますか？ （注：イベント駆動プログラミングの学習に関する私の質問と実際に機能的に同じ質問であるかどうかはわかりません）

21 design-patterns  learning  books  architectural-patterns  asynchronous-programming 

エンティティコンポーネントシステムアーキテクチャは、定義上、オブジェクト指向ですか？それは私にとってより手続き的または機能的だと思われます。私の意見では、オブジェクト指向言語で実装することを妨げるものではありませんが、堅実なオブジェクト指向の方法で実装することは慣用的ではありません。 ECSはデータ（E＆C）を動作（S）から分離しているようです。証拠として： アイデアは、エンティティにゲームメソッドを埋め込まないことです。 そして： コンポーネントは、特定の目的に必要な最小限のデータセットで構成されます。 システムは、特定のコンポーネントを持つエンティティのセットを使用する単一目的の機能です これはオブジェクト指向ではないと思います。オブジェクト指向になることの大部分は、データと振る舞いを組み合わせることだからです。 証拠として： 対照的に、オブジェクト指向のアプローチは、プログラムの残りの部分から直接アクセスできない場所にデータを配置することをプログラマに促します。代わりに、データにバンドルされている一般にメソッドと呼ばれる特別に記述された関数を呼び出すことにより、データにアクセスします。 一方、ECSは、行動からデータを分離することのすべてのようです。

20 design-patterns  object-oriented  functional-programming  architectural-patterns  entity-component-system 

私は最近CQRS / MediatRを調査しています。しかし、ドリルダウンすればするほど、それが好きではなくなります。おそらく私は何か/すべてを誤解しました。 だから、これをあなたのコントローラーをこれに減らすと主張することから、それは驚くほど始まります public async Task<ActionResult> Edit(Edit.Query query) { var model = await _mediator.SendAsync(query); return View(model); } Thin Controllerのガイドラインに完全に適合します。ただし、非常に重要な詳細-エラー処理は省略します。 Login新しいMVCプロジェクトからのデフォルトアクションを見てみましょう public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; if (ModelState.IsValid) { // This doesn't count login failures towards account lockout // To enable password …

16 c#  asp.net  architectural-patterns 

タイトルには「Circular Dependency」と書かれていますが、それは正しい表現ではありません。私にはデザインがしっかりしているように見えるからです。 ただし、次のシナリオを検討してください。青い部分は外部パートナーから提供され、オレンジは私自身の実装です。またConcreteMain、複数あると仮定しますが、特定のものを使用したいと思います。（実際には、各クラスにはさらにいくつかの依存関係がありますが、ここでは単純化しようとしました） すべてをDepency Injection（Unity）でStackOverflowExceptionインスタンス化したいのですが、明らかに次のコードを取得します。これは、RunnerがConcreteMainのインスタンス化を試行し、ConcreteMainにはRunnerが必要だからです。 IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); どうすればこれを回避できますか？これをDIで使用できるように構成する方法はありますか？私が今しているシナリオは、すべてを手動で設定することですが、ConcreteMainそれをインスタンス化するクラスに強い依存関係を置きます。これは私が回避しようとしているものです（構成にUnityの登録がある場合）。 以下のすべてのソースコード（非常に単純化された例！）; public class Program { public static void Main(string[] args) { IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); Console.WriteLine("invoking runner..."); runner.DoSomethingAwesome(); Console.ReadLine(); } } public …

15 architecture  dependency-injection  architectural-patterns 

私は独学で初心者っぽいコーダーなので、プログラマーの専門用語に釘付けにならなければ謝罪します。 私は、データのクエリからレポートを生成するツールを本質的に作成する開発者に継続的に更新されるデータを提供するプロジェクトに取り組んでいます。 関係者全員が、データ値（スキーマではなく、ドメイン/値自体）をレポート生成プログラムにハードコーディングする必要があると考えているようです。 たとえば、人員について報告しているとします。レポートは各部門の見出しを持つカテゴリに分割され、各部門の見出しの下に役職の小見出しが表示され、各小見出しの下に従業員のリストが表示されます。開発者は、部門と役職をハードコーディングしたいと考えています。一方、実行時にそれらをクエリし、レコードでソートし、そこにある値に基づいてレポートヘッダーを動的に生成できると思います。 潜在的な値のリストは時間とともに変化するため（たとえば、部門の作成/名前の変更、新しい役職の追加など）、コードを継続的に更新する必要があります。私は、コードのメンテナンス手順をスキップして、レポートを動的に整理できるように思えます。 私は開発者ではないので、何が欠けているのだろうと思っています。このようなツールに値をハードコーディングするとどのような利点がありますか？これは通常、プログラムの設計方法ですか？

13 design  architecture  architectural-patterns  dynamic-data 

私と非常によく似たパブリッシュ/サブスクライブおよびReactorパターン。彼らはどう違いますか？ どちらのパターンでも、メッセージは間接的にサブスクライバーに渡されます（リアクターパターンのリスナー）。 オブザーバーパターンは、他の2つのパターンとも非常に似ていると思います。 これらのパターンの主な違いは何ですか？

11 architectural-patterns 

2つのクラスDogと、Cat両方がAnimalプロトコルに準拠している（Swiftプログラミング言語に関しては、Java / C＃のインターフェースになる）と考えてください。 犬と猫の混合リストを表示する画面があります。Interactor舞台裏のロジックを処理するクラスがあります。 ここで、ユーザーが猫を削除するときに確認アラートを表示します。ただし、犬はアラートなしですぐに削除する必要があります。条件付きのメソッドは次のようになります。 func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } このコードはどのようにリファクタリングできますか？それは明らかににおいがする

10 architecture  refactoring  software  architectural-patterns  polymorphism 

だから私は異なるクラスのオブジェクトを作成するファクトリーを持っています。可能なクラスはすべて抽象祖先から派生しています。ファクトリーには構成ファイル（JSON構文）があり、ユーザーの構成に応じて、作成するクラスを決定します。 これを実現するために、ファクトリはJSON解析にboost :: property_treeを使用します。彼はptreeをウォークスルーし、どの具象オブジェクトを作成するかを決定します。 ただし、製品オブジェクトには多くのフィールド（属性）があります。具体的なクラスにもよりますが、オブジェクトには約5〜10個の属性があり、将来的にはさらに増える可能性があります。 そのため、オブジェクトのコンストラクターがどのように見えるかわかりません。私は2つの解決策を考えることができます： 1）製品のコンストラクターはすべての属性をパラメーターとして想定しているため、コンストラクターは最終的に10個以上のパラメーターになります。これは醜く、長くて読めないコード行につながります。ただし、利点は、ファクトリーがJSONを解析し、正しいパラメーターでコンストラクターを呼び出すことができることです。製品クラスは、JSON構成のために作成されたことを知る必要はありません。JSONや設定が含まれていることを知る必要はありません。 2）製品のコンストラクターは、property_treeオブジェクトという1つの引数のみを想定しています。次に、必要な情報を解析できます。構成内の情報が欠落しているか範囲外の場合、各製品クラスは適切に対応できます。ファクトリは、いくつかの製品に必要な引数を知る必要はありません。ファクトリーは、誤った構成の場合の対応方法を知る必要もありません。また、コンストラクターインターフェイスは統一されており、小さいです。ただし、デメリットとして、製品は必要な情報をJSONから抽出する必要があるため、JSONがどのように構成されているかを認識しています。 私は解決策2）を好む傾向があります。ただし、これが適切なファクトリパターンであるかどうかはわかりません。JSON構成で作成されていることを製品に通知するのは、どういうわけか間違っていると感じます。一方、新製品は非常に簡単に導入できます。 それについての意見はありますか？

10 design-patterns  object-oriented  c++  architectural-patterns  factory-method 

設計している次の機能のパターンまたはアーキテクチャガイダンスを探しています。基本的に、これは複数のエクスポートターゲットを備えたエクスポート機能であり、新しいエクスポートターゲットをプラグインする際に多くのコア変更を必要としない場合に十分に汎用的にする方法を探しています。エクスポートターゲットでは、PDF、PowerPointプレゼンテーション、Wordドキュメント、RSSなど、さまざまな種類の出力を単に参照しています。JSONとXMLで表されるデータの基本セットがあります。このデータは、画像（任意の数またはエクスポートタイプ（PNG、JPG、GIFなど）を使用）、グラフ、テキスト表現、表などを作成するために使用されます。 私は、すべてのレンダリングとレイアウトを、さらにエクスポートターゲットの追加を処理するある種のレンダリングまたはレイアウトエンジンに抽象化する方法を見つけようとしています。これにどのように取り組むかについてのヘルプ/提案/リソースは大歓迎です。前もって感謝します。 私が達成しようとしていることを図で表したもの。

10 patterns-and-practices  architectural-patterns 

現在、クラシックなn層アプリケーションがあります：DB / Webサービス/フロントエンド。他のコンポーネントがありますが、基本的なレイアウトです。 アプリケーションの可用性を改善する主な理由は3つあります。 私たちのホストは時々（すべてのように）停止を経験し、私たちは顧客への影響を最小限にしたいので、たとえば、データセンターAがダウンした場合、彼らはデータセンターBをオンにします。 バージョンをアップグレードすると、メンテナンスのためにサイトがシャットダウンされ、通常は数時間かかります（移行スクリプトなど）。ユーザーには、ダウンタイムを最小限に抑えて、よりシームレスな移行を望んでいます（サーバーAのアップグレード中にサーバーBを使用します）。 オプションとして、私たちの顧客は世界中にあり、私たちは彼らの接続が不安定である可能性があるにもかかわらず、可能な限り最高の体験をしてもらいたいと思っています（インドの開発者と一緒に働いた人は誰でも私が何を言っているか知っているはずです）。理想的には、私たちは彼らのオフィスにサーバーを接続できるようにしたい（または彼らの都市の近くのデータセンターを使用できる）ようにしたい、そしてそれは私たちのアーキテクチャにシームレスに統合するだろう。 リモートで99％の可用性を必要とせず、95％も必要としません。ドキュメント管理アプリです。誰も気にしない。ただし、移行には時間がかかる場合があり、世界中にお客様がいるため、お客様が1日のほとんどの時間にわたって仕事をすることができない場合があります。 SQLの部分については、「適切な」DBAがいない場合でも、SQLの可能性（レプリケーション、ミラーリングなど）について知っています。DB側では、このためのリソースを見つけるのは非常に簡単です。セッションやコードの保存など、他のすべてが難しいのは何ですか。Webサービスサーバーがダウンした場合、UIはそれを切り替える必要があることをどのように認識しますか？セッションはどのようにサーバー間で保持されますか？ 残念ながら、私たちの誰もこの分野での経験がなく、どこから探し始めればよいかさえわかりません。このためのベストプラクティスはありますか？デザインパターン？ライブラリー（お金がないため、無料で使用できます）？ ASP.NetとSQL Serverを使用しており、中央にWCF Webサービスがあります。Windowsサービスはたくさんありますが、ミッションクリティカルではありません。Webサイトを処理する方法がサービスに適用できると思います。 ほとんどのクラウドプラットフォームがこのための組み込みシステムを提供していることを理解していますが、私たちのシステム管理者はすべてを自分で管理し、誰にも依存しないことを望んでいるため、クラウドホスティングは不可能です。

9 architecture  architectural-patterns