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

現在の状況 私たちは、マイクロサービスアーキテクチャでオンラインショッピングWebアプリケーションを実装しています（そして現在保守しています）。 要件の1つは、エクスペリエンスと最終的な注文をカスタマイズするために、顧客がカートに追加するものにルールを適用できる必要があることです。明らかに、ビジネスルールエンジンを導入する必要があり、このために特定の「マイクロサービス」を実装しました（まだそう呼べる場合）。 1年の間に、このルールエンジンはますます複雑になり、より多くのデータ（カートのコンテンツだけでなく、ユーザー情報、役割、既存のサービス、請求情報など）が必要になりました。それらのルールを計算します。 現時点では、shopping-cartマイクロサービスは他のマイクロサービスからこのデータをすべて収集しています。このデータの一部はで使用されますがshopping-cart、ほとんどの場合、主にルールエンジンのフィードに使用されます。 新しい要件 これで、同様の要件にルールエンジンを再利用する他のアプリケーション/マイクロサービスが必要になりました。したがって、現在の状況では、ルールエンジンを呼び出すことができるように、同じ種類のデータを送信し、同じマイクロサービスを呼び出し、（ほぼ）同じリソースを構築する必要があります。 そのまま続行すると、いくつかの問題に直面します。 誰もが（ルールエンジンを呼び出して）データのフェッチを再実装する必要があります（自分でデータを必要としない場合でも）。 ルールエンジンへの要求は複雑です。 この方向で続けると、多くの要求のためにこのデータをネットワーク全体に転送する必要があります（μsAがルールエンジンを呼び出すμsBを考えますが、Aはルールエンジンが必要とするデータの一部を既に持っています）。 shopping-cart すべてのデータ取得により巨大になりました。 おそらく多くのことを忘れてしまいます… これらのトラブルを回避するために何ができますか？ 理想的には、ルールエンジンの複雑さを増やさないようにします。また、ボトルネックにならないように確認する必要があります。たとえば、一部のデータはフェッチに時間がかかります（10秒以上）ためshopping-cart、ルールを呼び出す前にデータが存在する可能性が高くなるようにプリフェッチを実装しましたエンジン、および許容できるユーザーエクスペリエンスを維持します。 いくつかのアイデア ルールエンジンに必要なデータをフェッチさせます。これにより、さらに複雑さが増し、単一の責任原則に違反します（さらに…）。 ルールエンジンがデータを取得する前にプロキシμsを実装します。 ルールエンジンが必要なすべてのデータを一度にフェッチするために呼び出す「データフェッチャー」μsを実装します（複合照会）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

マイクロサービスが独自の承認を処理する必要がありますか、それともマイクロサービスのすべてまたはサブセット（同じビジネスドメイン内）で共有される個別の承認サービスを使用する方が良いと思いますか？ 私にとって後者は、変更の適用、ポリシーの実施を容易にするため、より理にかなっています。DRYなどです。ただし、あらゆる種類のサービスがルールを1か所にダンプすることで簡単に手に負えなくなる可能性があり、ネットワークのオーバーヘッドも心配します。 何かご意見は？

12 architecture  authorization  microservices 

2つのアーキテクチャの違いは、ハーバードアーキテクチャの命令とデータの分離であることを理解しています。しかし、どのタイプのシステムを使用しているかをどのようにして知ることができますか？システムがフォン・ノイマンかハーバードかを決定するようなプログラムを書くことは可能ですか？別のアーキテクチャがありますか、またはこれらのアーキテクチャのみが知られていますか？

12 architecture  computer-architecture 

そのため、TDDを介してデータアクセスレイヤーを作成してきましたが、やや懸念がありました。私はむしろ間違った道を進んで行きたくないので、私の考えがきれいなアーキテクチャに沿っているかどうかを確認するように皆さんにお願いしたいと思いました。 私のデータアクセスレイヤー（略してDAL）内のメソッドは非常に単純です。これらはデータベース内のストアドプロシージャと一致しており（これを呼び出して物事をきれいにする方法はありません）、プロシージャと同じパラメータが含まれています。次に、データベースに接続し、クエリ結果を返します。次に例を示します。 public int DeleteRecord(int recordId) { recordId.RequireThat("recordId").NotZeroOrLess(); List<SqlParameter> parameters = new List<SqlParameter>(); parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId}); return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray()); } 私は結果セットで何も意味のあることをしていないので、これはこのタイプのメソッドには完全に機能します。コマンドが機能したことを確認したいだけなので、非クエリの結果、つまり影響を受けた行だけを返し、その番号を使用してロジックを検証できます。 ただし、別のDALメソッドで、レコードをロードしたいとします。マイロード手順が実行されようとしているselectsテーブルの束と戻っに対してDataSet、私はビジネスを作成する必要があり、私のDALは使用方法内のオブジェクトかどうかと戦っていますDataSet、または私のビジネスオブジェクトの場合自身がちょうど持っている必要がありますLoad()取得するメソッドをDataSetDALから、そして基本的にそれ自身を埋めます。 DALを介してそれを行うと、Business Objectsのロジックが少なくなります（これは単なる選択ロジックですが、それでもロジックです）が、DALを少し混雑させて、本当にすべきでないことをしているように感じさせますやってる 皆さんはどう思いますか？

12 c#  .net  architecture  database  business-logic 

私は次の用語についてかなり混乱しています。 ソフトウェアアーキテクチャ ソフトウェアアプリケーションアーキテクチャは、パフォーマンス、セキュリティ、管理性などの一般的な品質属性を最適化しながら、すべての技術的および運用上の要件を満たす構造化ソリューションを定義するプロセスです。さまざまな要因に基づいた一連の決定が含まれ、これらの決定はそれぞれ、アプリケーションの品質、パフォーマンス、保守性、および全体的な成功に大きな影響を与える可能性があります。（マイクロソフト） システムアーキテクチャー システムアーキテクチャは、システムの構造、動作、およびその他のビューを定義する概念モデルです。1アーキテクチャ記述は、システムの構造と動作に関する推論をサポートする方法で編成された、システムの正式な記述と表現です（wiki） クラス図 ソフトウェアエンジニアリングでは、Unified Modeling Language（UML）のクラス図は、システムのクラス、その属性、操作（またはメソッド）、およびオブジェクト間の関係を示すことにより、システムの構造を記述する静的構造図の一種です。（wiki） これらの説明を読んだ場合、これらはすべてアプリケーションの異なるモジュール間の相互作用を説明しています。しかし、これらの違いは何ですか？ これらの用語を比較するために私が考え/試みたもの： クラス図はシステムアーキテクチャの形式ではありません。上記の説明（structure, behavior, and more views of a system）は、アーキテクチャに実装の詳細が存在しないことを意味するのに対し、クラス図は実装を記述し、おそらくアーキテクチャではなく設計の方向にありますか？ ソフトウェアアーキテクチャはアプリケーション自体に焦点を合わせているのに対して、システムアーキテクチャは外部対話（データベースなど）も含むアーキテクチャだと思いますか？

11 design  architecture  class-diagram 

複数の開発者がいる分散システムを含むソフトウェア開発プロジェクトでは、論理および物理アーキテクチャの図を作成することがベストプラクティスですが、私の経験では、これらの図は常にプロジェクトの開始時に適切に管理されていますが、プロジェクトのリリース時に更新されませんメンテナンスフェーズが開始されます。 多くの分散プロセスを持つ複雑なプロジェクトの場合、最初のリリースの前であっても、誰も知識を持っていないため、ダイアグラムはすぐに古くなったり不正確になったりする傾向があります。 このような背景から、コミュニティに次の質問をしたいと思います。 正確で最新の論理および物理アーキテクチャ図を作成することはどれほど重要ですか？ それらを最新の状態に保つのに役立つツールやプロセスはありますか？ それらを最新の状態に保つ責任は誰にありますか？システム管理者、開発者、QAチームはどのように貢献できますか？

11 design  architecture  testing 

BLがCRUDを実行するためにDAL（またはDALのインターフェース）のメソッドを呼び出す責任を負った3層アーキテクチャーよりも、オニオンアーキテクチャーにのみ利点があると思います。タマネギは、関心事、テスト容易性、保守容易性のより良い分離があり、よりきれいです。 だから、オニオンアーキテクチャはすべての面で本当に優れており、3層アーキテクチャは物事を行うための古い方法にすぎません。または、3層アーキテクチャを使用したい場合、いくつかのシナリオがあります。

11 design  architecture  layers  n-tier  onion-architecture 

新しいプロジェクトが進行中です。現時点では、開発者はチームAとチームBの2つのチームに分かれています。このプロジェクトには、開発スタック全体での開発が必要な2つの部分があります。以下に示す非常に単純化されたスタックのサンプル： プロジェクトの各部分はスタック全体にわたる開発を必要とするため、通常はチームB内で作業を分解し、異なる部分間の相互作用を設計および実行するフルスタック開発者アプローチを期待します。 しかし最近、チームAがスタックの特定の部分を担当することを望んでいることを学びました。チームは、2つのチームの分割を提案しています。チームBからの開発はありません。分割は次のようになります。 私にはこれは非常に不自然に感じます。各チームには、これらを達成するための異なる明確な目標とタイムスケールがありますが、チームBは機能を実装するためにチームAに依存します。提案された解決策は、共通のインターフェイスが事前に定義されていることです（おそらくプロジェクトには2年のタイムスケールがあり、多数になる可能性があります）。チームAは、独自の目標を設定しているにもかかわらず、これらのインターフェイスに必要なビットを早期に開発し、チームBは、すぐに短期間のすべての呼び出しをスタブして、進行できるようにします。 私はこのアプローチについて懸念があります： インターフェイスは変更される可能性があり、チームAは変化する要件に対応するための帯域幅または時間がない場合があります。 チームAのコードのバグにより、チームBの進行が妨げられる可能性があります。また、チームAが異なる優先順位キューを持っているため、これらを修正する優先事項ではない可能性があります。 チーム全体に広がる知識の欠如-チームBは、内部で何が起こっているのかを完全に理解していない可能性があり、そのために設計上の決定が下される可能性があります。 業界の多くの企業にはサブチームがあり、これに対処できる必要があることが示唆されています。私の理解では、一般的に、チームは当初の予想方法（フルスタック）に分割されるか、以下のようにテクノロジースタックを分割します。 ですから、私は他の業界が何をしているかを知りたいと思っています。ほとんどの分割は垂直/水平ですか？対角線分割は意味がありますか？対角線の分割が発生した場合、私の懸念は有効であると思われ、チームBが懸念すべきことは他にありますか？私はおそらく、チームBの成功または失敗の責任を負うことに注意してください。

11 architecture  programming-practices  development-process  team 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 抽象マシン（Turingマシンなど）とコンピューターアーキテクチャ（仮想マシンのアーキテクチャ、Von Neumannのアーキテクチャを含む）の間には常に繋がりがありません。だから、私はそれらがどのように関係しているか知りたいですか？一方が他方にどのように影響しますか？参考文献も歓迎します。ありがとう。

11 architecture 

2つの関連システムを開発しています。そのうちの1つ（A）は、お客様のマシンにインストールされます。残りの（B）は私の組織で使用されます。 各システムには独自のデータベース（リレーショナル）があり、スキーマは異なります。ただし、両方のシステムを同期する必要があります。さらに、Bの一部の変更はすべてのクラスAシステムにエクスポートする必要があり、その他は特定のシステムにのみエクスポートする必要があります。 一部のお客様はインターネットに接続していないため、場合によっては、ファイルの交換を介して同期を行う必要があります。 そのため、次のようにこの問題を解決する予定です。 各システムは、データベースの変更ログを保持しています。MongoDBで実装する予定です。 システムが同期プロセスを初期化するとき、ログから行われたすべての変更を取得します。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。 他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要な場合、システムは存在する可能性のある競合を解決する必要があります。 最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。 このアプローチは実行可能で、スケーラブルでエレガントですか？どのような変更または追加を行いますか？

11 architecture  data  synchronization 

コーディングは実際にはそれほど難しくありません。難しい部分は、理にかなっており、読みやすく、理解可能なコードを書くことです。だから、私はより良い開発者を獲得し、強固なアーキテクチャを作りたいと思っています。 それで、私はビデオゲームでNPCのアーキテクチャを作成したいと思います。これは、Starcraft、Age of Empires、Command＆Conquersなどのようなリアルタイム戦略ゲームです。したがって、さまざまな種類のNPCがあります。A NPCは、これらの多くの能力（メソッド）に1を持つことができますBuild()、Farm()とAttack()。 例： 労働者がすることができますBuild()し、Farm() 戦士缶Attack() 市民缶Build()、Farm()とAttack() 漁師ができるFarm()とAttack() これまでのところすべてが明確であることを願っています。 だから今、私は私のNPCタイプとその能力を持っています。しかし、技術的/プログラム的な側面を見てみましょう。 さまざまな種類のNPCに適したプログラムアーキテクチャは何でしょうか。 さて、基本クラスを持つことができました。実際、これはDRYの原則を守る良い方法だと思います。WalkTo(x,y)すべてのNPCが移動できるため、基本クラスのようなメソッドを持つことができます。しかし今、本当の問題に取り掛かりましょう。自分の能力をどこで実装しますか？（覚えておいてください：Build()、Farm()およびAttack()） 能力は同じロジックで構成されるため、各NPC（Worker、Warrior、..）にそれらを実装することは、DRYの原則に迷惑をかける/破るでしょう。 さて、基本クラス内に能力を実装できました。NPCは、能力Xを使用することができる場合、これは検証というロジックのいくつかの種類が必要になりIsBuilder、CanBuild、..私は私が表現したいものを明確だと思います。 しかし、私はこの考えにあまり気分がよくありません。これは、機能が多すぎる肥大化した基本クラスのように聞こえます。 プログラミング言語としてC＃を使用しています。したがって、ここでは多重継承はオプションではありません。手段：のような追加の基本クラスがあるFisherman : Farmer, Attackerと機能しません。

11 c#  architecture  multiple-inheritance 

そうだった 長年にわたって、ソフトウェアソリューションを次のように整理してきました。 データにアクセスするビジネスを抽象化するデータアクセス層（DAL） ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー（BLL） ユーティリティ（Util）は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。 もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。 今のやり方 過去4年ほどの間、私はMicrosoftのEntity Framework（私は主に.NET開発者です）を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私のDALが使っていた仕事：データベースに対してCRUDを実行するビジネスを抽象化します。 したがって、通常、次のようなメソッドのコレクションを持つDALになります。 public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 次に、BLLでは、このメソッドは次のように使用されます。 public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } BLLには通常、さらに数行のロジックが適用されるため、これはもちろん簡単な例ですが、そのような限られた範囲でDALを維持するのは少し過剰に思えます。 DALを放棄して、単にBLLメソッドを次のように記述する方が良いと思いませんか。 public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns 

私はWebアプリケーションを設計していますが、自動化された電子メールの送信を管理するためのアーキテクチャをどのように設計するのでしょうか。 現在、この機能をWebアプリに組み込み、ユーザーの入力/操作（新しいユーザーの作成など）に基づいてメールを送信しています。問題は、メールサーバーに直接接続するのに数秒かかることです。アプリケーションの規模を拡大すると、これは将来的に大きなボトルネックになるでしょう。 システムアーキテクチャ内で大量の自動化された電子メールの送信を管理する最良の方法は何ですか？ 大量のメールが送信されることはありません（1日最大2000）。メールをすぐに送信する必要はありません。最大10分の遅延が問題ありません。 更新：メッセージキューが回答として提供されましたが、これはどのように設計されますか？これはアプリで処理され、静かな期間に処理されますか、またはキューを管理するだけの新しい「メールアプリ」またはWebサービスを作成する必要がありますか？

11 web-development  architecture  web-applications  web-design 

ほとんどのクラスが1つのパッケージに配置されている大規模なコードベースをリファクタリングしています。モジュール性を高めるために、各機能のサブパッケージを作成しています。 パッケージ依存関係グラフにはループがあってはならないことをどこかで覚えていましたが、次の問題を解決する方法がわかりません：FigureパッケージfigureにLayoutあり、パッケージlayoutにLayoutあり、レイアウトを実行するために図が必要なので、パッケージlayoutはパッケージに依存しますfigure。しかし、一方で、a FigureはFigure、その中に他のを含むことができ、独自のを持ちLayout、packageをpackageにfigure依存させますlayout。 実装するContainerインターフェイスを作成FigureしてLayoutパッケージに入れるなど、いくつかのソリューションがあります。これは良い解決策ですか？他の可能性はありますか？ ありがとう

11 java  architecture  packages 

私が質問しようとしていることの良い例は、Facebookの新しいタイムライン機能です。最初は、タイムラインへのアクセスが許可されたのは一部のみでした。機能の動作がより強固になり、バグが修正されたため、追加のユーザーが機能へのアクセスを許可されました。後日、大規模なユーザーグループがこの機能へのアクセスを許可されましたが、現在では、すべてのユーザーに対する一般的な機能です。開発チームはこのタイプの機能の展開をどのように管理しますか？ コード内の構成ファイルと条件付きifステートメントを介して、テストまたは実稼働中に何かが存在する場合、構成設定を使用してアクセスを選択的に制御するというアイデアを試しました。単純な機能ではこれで問題ありませんが、より大きな機能セットでこれを実装しようとすると、管理できなくなると思います。 この方法で機能のロールアウトを管理する最良の方法は何でしょうか？

11 architecture  web-applications  development-process