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

さまざまなプログラムからのアラートメッセージを処理し、それらのアラートを処理して電子メールを介してダウンコンシューマーに送信できるシステムを作成したいと考えています。これはすべて1つの内部ネットワークに含まれます。 基本的なアーキテクチャを次のようにしたいと思います。 私の現在の主な関心事は「メッセージハンドラー」ビットです。これが私の「ソートAPI」になります。このシステムのすべてのコンポーネントが、データベースへのすべての書き込みを処理するAPIにデータを送信するようにします。このアプローチは、セキュリティを簡素化し、より複雑なDBクエリの多くを1つのプログラムに含めることができるため、より簡単だと思います。 懸念事項は、これを言語にとらわれないようにしたいことです。つまり、どのコードでもメッセージをハンドラに送信して、メッセージを解釈できるようにする必要があります。これは、JSONフラットファイルを介して、またはプログラムへのREST呼び出しを介して（下流のアプリケーションに柔軟性を与える）希望します。 私の質問は メッセージハンドラーを気にする必要がありますか？それとも、下流のアプリケーションと他の2つのコンポーネント（管理コンソールとアラートマネージャー）への直接データベースアクセスを許可するだけで簡単になりますか？ このようにして、DBテーブルへのINSERTが有効である限り、任意のアラートを挿入できます。 私は貿易でソフトウェアデザイナーではないので、失礼します。ただ、自由な時間にプロジェクトをやってもらいたいのです。

10 design  design-patterns  architecture  api  api-design 

サーバーレスアーキテクチャの主な利点は、そのようなプログラムが継続的に実行するために専用サーバーを必要としないことです。次に、要求時に呼び出され、関数の終了時に停止します。 つまり、レスポンシブであるためには、サーバーレスプログラムをすばやく起動する必要があります。次に、データベース接続などの時間のかかるアクションをどのように処理しますか？それは毎回データベースに接続しますか、それともサーバー接続で行われるような関数呼び出しのためにデータベース接続を個別に管理しますか？

10 architecture  server  backend 

私はアマチュア開発者であり、これまでのすべてのプログラムは、コード内に文書化できるほど単純でした。コードを読んでいる間、私が何をしているのか、そのようなアクションは明らかでした（私の標準的なテストは、6か月後にコードを見て、最初に読んだときにすべてを理解することでした-私は短いメモリスパンを持っています）。 私は今、プログラム間のさまざまな相互作用を覚える能力を超えてプログラムに直面しています。 コード自体 データベース内のインデックス さまざまなモジュール間の相互作用（「ワーカー」コアコードと「ライブラリ」モジュール） 私の現在のドキュメントはホワイトボードで、コード、データベースインデックス、実行中のアクション、状態変化などを指すあらゆる種類のボックスと矢印があります。参考までに、混乱の断片： 私の質問は、より複雑な製品のドキュメント化のための標準または名前付きのベストプラクティスのセット（これは特定の名前でグループ化された一連のプラクティスであるという意味で名前が付けられている）があるかどうかです。 私が探す必要があるキーワードは何ですか（「ドキュメントソフトウェアアーキテクチャ標準」での一般的な試みと同様のバリエーションは、通常、ワークフローまたはビルディングアーキテクチャCADシステム用のソフトウェアにつながりました）。 また、高レベルの説明には一般的なベストプラクティスがなく、誰もが独自の哲学を構築することも期待しています。

10 architecture  documentation 

Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST API呼び出しを通じてこれらのサービスにアクセスできます。 これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？ クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか？ または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか？

10 architecture  rest  microservices 

新しいコンピューターアーキテクチャのプロバイダーは、定期的に新しいプログラミングモデル（最近のGPGPU向けのCUDA / OpenCLなど）の導入を試み、プラットフォームの並列処理の制御インターフェイスとしてC / POSIXを置き換えます。（Poss＆Koening、AM3：2015年のメニーコア向けハードウェアUnixアクセラレータに向けて） なぜアーキテクチャ設計者は、並列プログラミングのためにC / POSIXに取って代わるために新しいプログラミングモデルを設計しようとするのですか？C / POSIXはマルチプロセッサにあまり適していませんか、それともC / POSIXの最初の作者はC / POSIX設計時に並列計算を必要としていませんでしたか？それとも、プログラマーがC / POSIXが提供できるよりも多くの機能を必要としているため、CUDA / OpenCLなどの新しい設計に頼っていますか？

10 architecture  multithreading  parallelism  posix 

「MVCでモデルが検証を処理する必要がありますか？」と読んでいたのは、検証ロジックがMVC Webサイトのどこにあるのか知りたいからです。上位回答の1行は次のようになります。「コントローラーは検証を処理し、モデルは検証を処理する必要があります。」 私はそれが好きでしたが、なぜビューでデータ検証を行わないのか、いくつかの理由で疑問に思いました。 ビューは通常、堅牢な検証サポート（JSライブラリ、HTML5タグ）を備えています ビューはローカルで検証できるため、ネットワークIOを削減できます UIはすでにデータタイプ（日付のカレンダー、数値のスピナー）を考慮して設計されているため、検証から1つの小さなステップになっています 複数の場所で検証することは、責任を分離するというMVCの概念に反するため、「両方で実行する」ことは不適切に思われます。コントローラでのみデータ検証を行うことは、本当に主要なアプローチですか？

10 architecture  mvc 

ほとんどのWebアプリケーションは要求/応答パラダイムに基づいていると言っても安全だと思います。PHPは、これらのオブジェクトを正式に抽象化したことがありません。1つのグループがこれを変更しようとしています：https : //github.com/php-fig/fig-standards/blob/master/proposed/http-message.md しかし、彼らは不変性の問題についてはある程度傍受された。一方では、要求/応答オブジェクトは通常、ライフサイクル中にほとんど変更を必要としません。一方、特に応答オブジェクトでは、多くの場合、HTTPヘッダーを追加する必要があります。 さらに、不変性がPHPの世界で実際に使用されたことはありません。 不変の要求/応答オブジェクトを使用すると、どのような利点がありますか jsonオブジェクトを返すとします。 $response = new JsonResponse($item); 素敵でシンプル。しかし、要求はクロスオリジンリソースシェアリング（CORS）要求であることがわかりました。応答を生成するコードは気にする必要はありませんが、下流のどこかに、必要なAccess-Controlヘッダーを追加するプロセスがあります。元の応答を維持し、追加のヘッダーを使用して新しい応答を作成する利点はありますか？それとも厳密にはプログラミングスタイルの問題です。 リクエストオブジェクトはもう少し興味深いです。同じように始まります： $request = new Request('incoming request information including uri and headers'); 初期情報を変更する必要はありません。ただし、リクエストが渡されると、処理情報を追加する必要が生じることがよくあります。たとえば、特定のリクエストに対して実行するアクションを決定するURLマッチャーがあるとします。 $request->setAttribute('action',function() {}); 実際にアクションを実行するのは、下流プロセスの責任です。不変の要求をラップする変更可能なRequestAttributesCollectionを使用することもできますが、実際には少し扱いに​​くい傾向があります。また、属性コレクションを除いて、不変のリクエストを持つこともできます。例外も扱いにくい傾向があります。この種の要件に対処した経験はありますか？

10 design  php  web-development  architecture 

主な問題 最も近代的なプログラミングプラットフォームはパッケージ管理のために持っている良いサポートを見て（と思うgem、npm、pipなど、）、それが促進し、疎結合アーキテクチャを作成するように、内部で開発されたパッケージで構成されたアプリケーションやシステムを設計する意味がありませんか？ 例 この例としては、データベースアクセス用のパッケージの作成や、システムの認証やその他のコンポーネント用のパッケージの作成があります。もちろん、これらも外部パッケージを使用します。次に、システムはこれらのパッケージをインポートして使用します-独自のコードベースにコードを含める代わりに。 考慮事項 私には、これはコードのデカップリングを促進し、保守性を支援するように思われます。ほとんどWebベースのデスクトップアプリケーションのようなものです（更新はほとんど自動的に適用され、単一のコードベースは単一の機能などに適用されます）。 これは合理的で健全なデザインコンセプトのように見えますか？これは、今日のアプリケーションを構造化する標準的な方法として実際に使用されていますか？

10 design  design-patterns  architecture  packages  coupling 

2つのスクラムチームが同じソフトウェアコンポーネントを使用する場合、そのコンポーネントの明確なアーキテクチャビジョンを提供し、コードベースの進化に合わせてこのビジョンを維持/開発する責任を持つのは誰ですか？スクラムでは、共同でコードを所有することになっているので、チームAが行った開発がチームBが行った開発に干渉しないようにする方法を教えてください。

10 architecture  scrum  code-quality  configuration-management 

私は、管理者がフィールドを含むフォームを定義できるシステムに取り組んでいます。定義されたフォームは、システムにデータを入力するために使用されます。フォームは、GUIを介して人間が入力する場合もあれば、別のシステムから報告された値に基づいて入力される場合もあります。 各フィールドについて、管理者はフィールドに許可される値を制限する検証ルールを定義できます。検証ルールは、「フィールドに入力された値はTrueまたはFalseである必要があります」から「フィールドに入力された値はデータベースのテーブルBの列Aに存在している必要があります」まで、任意です。管理者はいつでもフィールドの検証ルールを変更できます。 このシナリオでは、各フィールドが正しく入力されていることを検証するのに最も適した場所は何だと思いますか？私は現在、主に2つのアプローチを考えています。 オプション＃1：ドメインモデルで検証する 各フィールドオブジェクトには、管理者が指定した検証ルールが含まれます。Fieldオブジェクトには、IValidatorへの参照も含まれます。フィールドの値を設定しようとすると、フィールドは指定された値と検証ルールをIValidatorに渡します。指定された値が有効でない場合、ValidationExceptionがスローされ、他のシステムへのGUI /インターフェイスで適切に処理されます。 長所： 検証ルールに違反するフィールドが誤って割り当てられたフィールドに対する強力な保護 短所： データアクセスレイヤーは、検証をバイパスし、現在の検証ルールに違反するフィールドを構築できる必要があります。管理者がフィールドの入力規則を変更しても、何年も前に入力されたフォームをレンダリングするときなど、古いデータに基づいてフィールドオブジェクトを構築できる必要があります。これは、フィールドを保存するたびに現在の検証ルールを保存することで解決できる可能性があります。 この設計では、フィールドモデルはIValidatorを介してデータアクセスレイヤー/リポジトリに間接的にリンクしています。ドメインモデルへのサービス/リポジトリの挿入は、一般的には嫌われているようです。 オプション＃2：サービスで検証する フィールドの値を設定するすべての試行が、検証ルールが確実に実行されるサービスを通過するようにしてください。検証ルールに違反している場合は、ValidationExceptionをスローします。 もちろん、以前はDBに永続化されていたFieldオブジェクトを作成する場合、データアクセス層はサービスを使用しません。 長所： 「サービス/リポジトリをドメインモデルに挿入しない」という考え方に違反していない。 フィールドを永続化するときに、現在の検証ルールを永続化する必要はありません。サービスは、フィールドの現在の検証ルールを単純に検索できます。履歴データを見ると、フィールドの値は変更されません。 短所： サービスを使用してフィールド値を設定する必要のあるすべてのロジックが実際にそうであるとは限りません。私はこれを大きな欠点だと考えています。誰かが「thisField.setValue（thatField.getValue（））」を書いているだけで、thisFieldの検証ルールに違反する可能性があります。これは、データアクセスレイヤーがフィールドを永続化しようとしているときに、フィールドの値が入力規則と一致するようにすることで軽減できる可能性があります。 私は現在、オプション＃2よりもオプション＃1を好みます。これは主にこれをビジネスロジックと見なしており、オプション＃2がシステムに不正なデータを導入するリスクが大きいと感じているためです。どちらのオプションを選択しますか、またはこのシナリオに適合する、説明した2つのオプションよりも優れた別のデザインはありますか？ 編集（検証の複雑さ） 現在のところ、検証ケースは比較的単純です。フィールド値は、数値、日付、時刻付きの日付、またはデータベース列の既存の値である必要があります。ただし、時間の経過とともに複雑さが徐々に増加すると思われます。たとえば、検証ソリューションは国際化を念頭に置いて構築する必要があります。日付などはロケール固有の構文で入力できます。 ここでは、オプション1に進むことを決定しました。ドメインモデルに多くの責任を割り当てないように注意してください。同様の状況に直面している人は、関連する質問を確認することもできます。階層化アーキテクチャでの検証と承認およびデータ入力検証-どこですか？いくら？。

10 design-patterns  architecture  domain-driven-design  validation 

私のカードゲームには良いアーキテクチャが思いつきません。ゲームの通常の設計方法を理解するのに助けが必要です。 まず、ゲームのルールについて説明します。 ゲームのルール セットアップ 4人のプレーヤーがいて、各2人がチームを形成します。 各プレイヤーは12枚のシャッフルカードを取得します テーブル（川）に4枚の盲目カードがあります プレイヤーの注文はこんな感じ 賭け 各プレーヤーは、100から160までの現在の賭けより大きい数をパスまたは選択できます 賭けは最初のプレーヤーから始まり、チームが合格するまでサークルします プレイヤーがパスすると、もうベットすることはできません ベッティングラウンドに勝ったチームは、ゲームに勝つために、少なくとも自分のベットに等しいポイントを集める必要があります。 ベッティングラウンドに敗れたチームは、チームが目標を達成することを許可してはなりません。 ベッティングラウンドに勝ったチームがすべてのポイントを取得した場合、他のチームは自分のベットに等しいマイナスのポイントを取得します ベッティングラウンドに敗れたチームがすべてのポイントを集めた場合、他のチームはダブルのマイナスポイントを獲得します ゲームの流れとポイントの収集 ベッティングラウンドに勝ったプレーヤー（キング）は、テーブルに残っているカードを4枚受け取ります。 その後、4枚のカードのセットを、プレイすることなくチームカードバンクに保存できます。 王は定規スーツとしてスーツを選び、他の人にそれを知らせます キングは手札のカードをテーブルに置くことからゲームを開始します。他の各プレーヤーはこの順序でプレイする必要があります 手札に同じカードのスーツがある場合、それらのカードの1つをプレイする必要があります。 彼らが持っていない場合、彼らは他のスーツをプレイすることができます 他のすべてのプレーヤーがハンドをプレーした後、ラウンドの勝者は次のようになります。 すべてのカードが同じ場合に最も高いカードを持っている人 「ルーラー」カードがある場合、最も高いカード ラウンドの勝者はカードを集めて銀行に置きます 前のラウンドに勝ったプレーヤーは次のラウンドを開始します これはみんなの手が空になるまで続きます カウントポイント 各ラウンドでの勝利は5ポイントです。これは、4枚のカードごとに少なくとも5点あることを意味します。 バンクにエースが10、5いると、それぞれ5ポイントが加算されます 私のデザイン クラス class Card { string suit; string rank } class Deck { List cards = []; List …

10 architecture 

大規模なシステムに変更を加えるとき、機能の一部が別の部分からデータを取得する必要があるという問題にしばしば直面しますが、それらは深く分岐した呼び出しツリーの異なる部分にあり、イベントリスナー、遅延呼び出しを経由している可能性があります。このようにして、簡単な変更ですばやく膨らませることができます。 Yossi Kreininのブログ投稿（http://www.yosefk.com/blog/i-want-a-struct-linker.html）からの引用： あなたはあなたがたくさん渡すいくつかの種類のデータ構造を持っています。すぐに、構造に関して最も価値のあるものは、それが保持するデータではありませんが、制御の毛のような流れを通してずっと利用できるという事実です。 グローバル変数は、コードを遠く離れたコードに「叫び」させる1つの古典的な方法ですが、問題があることがわかっています。動的スコープ変数はより制限された方法ですが、同様に問題があります。 この問題を解決することを目的としたプログラミング言語の研究はありますか？静的チェック、簡単な単体テスト、その他の機能を備えたまま、予期しないデータフローを大規模なコードベースに簡単に追加できますか？

10 programming-languages  architecture 

次のアーキテクチャの問題に対する適切な解決策を見つけるのに問題があります。 この設定（下図）には2つのデータソースがあり、データソースAはタイプFooのアイテムのプライマリソースです。Fooの追加情報を取得するために使用できるセカンダリデータソースが存在します。ただし、この情報は常に存在するとは限りません。 さらに、データソースAを使用してタイプBarのアイテムを取得できます。ただし、各バーはFooを指します。ここでの問題は、各バーがFooを参照する必要があることです。Fooには、データソースBによって拡張された情報も含まれます。 私の質問は、SubsystemA.1とDataSourceBの間の密結合を取り除く方法ですか？

10 architecture 

私は現在、2つの実行可能なソフトウェア設計/ソリューションから選択しています。ソリューション1は実装が簡単ですが、一部のデータを独自の形式でロックし、後で変更するのが困難になります。ソリューション2は実装が困難ですが、後で変更する方がはるかに簡単です。 これについてYAGNIに行くべきか、それとも意思決定に出口費用を組み込むべきか？または別の質問として、出口コストはTCOの一部ですか？ これを持って顧客に戻り、出口費用が適切であるかどうかを質問することを考えていますが、コミュニティが最初に何を考えているのか知りたいのですが。 PS出口費用は正しい用語ですか？

10 design  architecture  terminology  decisions 

アプリケーションフレームワークで、パフォーマンスへの影響を無視できる場合（最大で1秒あたり10〜20イベント）、 モジュール間の通信の優先媒体として使用するのに、より保守的で柔軟なものは何ですか？イベントまたは先物/プロミス/モナド？ イベント（pub / sub、メディエーター）は疎結合を許可するため、より保守しやすいアプリであるとよく言われます...私の経験ではこれが否定されます。20以上のイベントがあると、デバッグが困難になり、リファクタリングも行われます-誰が、いつ、なぜ使用するのかを確認するのは非常に難しいためです。 約束（私はJavascriptでコーディングしています）は、イベントよりも醜くて気難しいものです。ただし、関数呼び出し間の接続を明確に確認できるため、アプリケーションロジックがより簡単になります。私が恐れていること。ただし、Promiseはそれらとのより強い結合をもたらすでしょう... PS：答えはJSに基づく必要はありません。他の関数型言語の経験は大歓迎です。

10 architecture  maintainability  async  event-programming  monad