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

私は最近、特定のプロジェクトの特定のクラスにチェーンのメソッドを実装して、コードの可読性を向上させることを提案しました。「便利なだけでなく、セマンティクスのために流fluentなインターフェイスを実装すべきではない」という回答を得て、提案を打ち切りました。私は、流interfaceなインターフェースを提案しているのではなく、読みやすさとコーディングの快適さを改善するためにメソッド自体を連鎖させる（両方とも混同される可能性があります）と回答しました。 とにかく、これは、おそらく何も返さないはずのメソッド（セッターなど）で常に「this」を返すことで、悪い習慣を負わされる可能性があると考えさせられました。 私の質問は、前の慣習を適用することを悪い習慣や虐待とみなすことができるのか、なぜなのか、ということです。パフォーマンス上の欠点はないと思いますか？

14 architecture  coding-standards  readability  method-chaining 

過去1年で、Dependency InjectionとIOCコンテナを使用して新しいシステムを作成しました。これは私にDIについて多くを教えてくれました！ ただし、概念と適切なパターンを学んだ後でも、コードを分離し、IOCコンテナーをレガシーアプリケーションに導入することは難しいと考えています。アプリケーションは、真の実装が圧倒されるほどの大きさです。値が理解され、時間が与えられたとしても。こんなことをする時間を与えられたのは誰ですか?? もちろん、単体テストをビジネスロジックに組み込むことが目標です！ テスト防止のデータベース呼び出しと絡み合っているビジネスロジック。 この記事を読みましたが、このLos Techiesの記事で説明されているように、Poor Man's Dependency Injectionの危険性を理解しています。私はそれが本当に何も切り離さないことを理解しています。 実装には新しい依存関係が必要になるため、システム全体で多くのリファクタリングが必要になることを理解しています。どんなサイズの新しいプロジェクトでも使用することは考えません。 質問： Poor ManのDIを使用して、レガシーアプリケーションにテスト容易性を導入し、ボールローリングを開始しても大丈夫ですか？ さらに、Poor ManのDIを真のDependency Injectionへの草の根アプローチとして使用することは、原則の必要性と利点を教育する価値のある方法ですか？ インターフェイスの背後でデータベース呼び出しの依存関係と抽象化を呼び出すメソッドをリファクタリングできますか？単純に抽象化することで、そのメソッドをテスト可能にします。これは、コンストラクターのオーバーロードを介してモック実装を渡すことができるためです。 今後、支援が得られると、プロジェクトを更新してIOCコンテナを実装し、抽象化を取り入れるコンストラクタを公開することができます。

14 architecture  dependency-injection  legacy  inversion-of-control 

タスクログシステムがあるとします。タスクがログに記録されると、ユーザーはカテゴリを指定し、タスクはデフォルトで「未処理」のステータスになります。このインスタンスでは、CategoryとStatusをエンティティとして実装する必要があると想定しています。通常、私はこれをします： アプリケーション層： public class TaskService { //... public void Add(Guid categoryId, string description) { var category = _categoryRepository.GetById(categoryId); var status = _statusRepository.GetById(Constants.Status.OutstandingId); var task = Task.Create(category, status, description); _taskRepository.Save(task); } } エンティティ： public class Task { //... public static void Create(Category category, Status status, string description) { return new Task …

14 architecture  domain-driven-design  repository  domain-model  entity 

コンテキスト：C＃を使用しています クラスを設計し、それを分離し、ユニットテストを容易にするために、すべての依存関係を渡します。内部的にオブジェクトのインスタンス化は行いません。ただし、必要なデータを取得するためにインターフェイスを参照する代わりに、必要なデータ/動作を返す汎用Funcsを参照するようにします。依存関係を注入するとき、ラムダ式を使用してそれを行うことができます。 私にとっては、単体テスト中に面倒なモックをする必要がないため、これはより良いアプローチのように思えます。また、周囲の実装に根本的な変更がある場合、ファクトリクラスを変更するだけで済みます。ロジックを含むクラスを変更する必要はありません。 ただし、これまでにIoCがこのように行われるのを見たことがないため、見落としがちな潜在的な落とし穴があると思います。私が考えることができるのは、Funcを定義しないC＃の以前のバージョンとのわずかな非互換性だけです。これは私の場合は問題ではありません。 より具体的なインターフェイスとは対照的に、IoCのFuncなどの汎用デリゲート/高階関数の使用に問題はありますか？

14 architecture  interfaces  inversion-of-control  delegates 

幅広い質問であることは承知しておりますので、できるだけ具体的にお話しさせていただきます。この質問は、技術的な質問よりも「組織的な」質問です。 これらの主なコンポーネントを持つマルチサイドプロジェクトがあります。 コアビジネスロジック（データモデル）をホストするサーバー コアビジネスロジックを使用するクライアントのバックオフィス コアビジネスロジックも使用するアプリケーションAPI（REST） アプリケーションAPIを使用するスマートフォンアプリ（iOSおよびAndroid）があります。 スマートフォンとは別のタブレットアプリ（android）があり、同じアプリAPIを使用しています。 すぐに、私はアクティブなクライアントで生産されます。そして、どんなプロジェクトでも、私はすべての異なるコンポーネントを長期にわたって維持する必要があります。つまり、以下のすべてをアップグレードできます。 サーバーのコアビジネスロジックのコード（バックオフィス、API、および副作用としてモバイルアプリで使用） API自体（スマートフォンアプリとタブレットアプリの両方で使用） すべてのモバイルアプリ（appstore / googleplay経由） もちろん、サーバー側の部分（コアビジネスロジックコードとAPIコード）は自分ですぐに変更できます。ただし、新しいモバイルアプリはappstore / googleplayでクライアントがダウンロードする必要があり、それらが最新であるかどうかはわかりません。 これらのアップグレードをスムーズに行い、クライアントにリスクを与えないようにするためのガイダンス、優れた実践のヒントを教えてください。 どのバージョンの「バージョン」を作成する必要がありますか？クライアントがモバイルアプリをアップグレードしなくても、すべてが確実に機能するようにするにはどうすればよいですか？私に仕事を楽にするために彼にアップグレードを強いるべきですか？ つまり、マルチサイドプロジェクトを長期にわたってライブにするには、どのように整理すればよいですか？

14 design  architecture  project-management  deployment  release-management 

サーバーに大量のイベントが流入し、平均して1秒あたり約1000イベント（ピークは〜2000）に対処しなければならない状況があります。 問題 私たちのシステムはHerokuでホストされ、比較的高価なHeroku Postgres DBを使用します。これにより、最大500のDB接続が可能になります。接続プーリングを使用して、サーバーからDBに接続します。 DB接続プールが処理できるよりも速くイベントが入ります 私たちが抱えている問題は、イベントが接続プールが処理できるよりも速く来るということです。1つの接続がサーバーからDBへのネットワークラウンドトリップを終了するまでに、n追加のイベントが入るよりも多く、プールに解放されます。 最終的に、イベントは蓄積され、保存されるのを待機します。プールに使用可能な接続がないため、タイムアウトし、システム全体が動作不能になります。 クライアントから遅いペースで問題のある高周波イベントを発信することで緊急事態を解決しましたが、その高周波イベントを処理する必要がある場合にこのシナリオを処理する方法を知りたいです。 制約 他のクライアントがイベントを同時に読み取りたい場合があります 他のクライアントは、DBにまだ保存されていない場合でも、特定のキーを持つすべてのイベントの読み取りを継続的に要求します。 クライアントはGET api/v1/events?clientId=1、クライアント1によって送信されたすべてのイベントを照会して取得できます。それらのイベントがまだDBに保存されていない場合でもです。 これに対処する方法に関する「教室」の例はありますか？ 可能な解決策 サーバーのイベントをキューに登録します サーバー上のイベントをキューに入れることができます（キューの最大同時実行数は400であるため、接続プールが不足することはありません）。 次の理由により、これは悪い考えです。 使用可能なサーバーメモリを使い果たします。スタックされたエンキューイベントは、大量のRAMを消費します。 サーバーは24時間ごとに1回再起動します。これはHerokuによって課される厳しい制限です。イベントがエンキューされている間にサーバーを再起動すると、エンキューされたイベントが失われます。 サーバーに状態が導入されるため、スケーラビリティが低下します。マルチサーバー設定があり、クライアントがキューに入れられたイベントと保存されたイベントをすべて読みたい場合、キューに入れられたイベントがどのサーバーに存在するかはわかりません。 別のメッセージキューを使用する メッセージキュー（RabbitMQなど）を使用して、メッセージをポンプで送り、もう一方の端にはDB上のイベントの保存のみを処理する別のサーバーがあると仮定します。 メッセージキューがエンキューされたイベント（まだ保存されていない）のクエリを許可するかどうかわからないので、別のクライアントが別のクライアントのメッセージを読みたい場合、DBから保存されたメッセージとキューから保留中のメッセージを取得できますそれらを連結して、読み取り要求クライアントに返送できるようにします。 複数のデータベースを使用し、それぞれが中央のDBコーディネーターサーバーでメッセージの一部を保存して、それらを管理します しかし、もう1つの解決策は、中央の「DBコーディネーター/ロードバランサー」で複数のデータベースを使用することです。イベントを受信すると、このコーディネーターはメッセージを書き込むデータベースの1つを選択します。これにより、複数のHerokuデータベースを使用できるようになり、接続の制限がデータベースの500倍になります。 読み取りクエリで、このコーディネーターはSELECT各データベースにクエリを発行し、すべての結果をマージして、読み取りを要求したクライアントにそれらを送り返すことができます。 次の理由により、これは悪い考えです。 この考えは...ええと..オーバーエンジニアリングのように聞こえますか？同様に管理するのは悪夢です（バックアップなど）。構築と保守は複雑で、絶対に必要でない限り、KISS違反のように聞こえます。 一貫性を犠牲にします。このアイデアを採用すれば、複数のDBでトランザクションを実行することはできません。

13 architecture  performance  scalability  event-sourcing 

私の考えを追加するために、質問は自明です： 私が読んだ限り、Clean archのプレゼンテーション層は、MVPのMVと同じ責任を負っています。 あるパターンを他のパターンではなく選択する方法は？

13 architecture  mvp 

例から始めましょう。 たとえば、exportDBスキーマに大きく依存するというメソッドがあります。また、「大きく依存する」ということは、特定のテーブルに新しい列を追加すると、頻繁に（非常に頻繁に）対応するexportメソッドが変更されることを知っています（通常、エクスポートデータにも新しいフィールドを追加する必要があります）。 プログラマーは、exportメソッドを変更することを忘れることがよくあります。これを確認する必要があるかどうかは明確ではないからです。私の目標は、プログラマーがメソッドを見るのを忘れたのか、エクスポートデータにフィールドを追加したくないだけなのかを明確に決定するようプログラマーに強制することexportです。そして、私はこの問題の設計ソリューションを探しています。 私には2つのアイデアがありますが、どちらにも欠点があります。 スマートな「すべてを読む」ラッパー すべてのデータが明示的に読み取られるようにするスマートラッパーを作成できます。 このようなもの： def export(): checker = AllReadChecker.new(table_row) name = checker.get('name') surname = checker.get('surname') checker.ignore('age') # explicitly ignore the "age" field result = [name, surname] # or whatever checker.check_now() # check all is read return result そのため、読み取られなかった別のフィールドが含まれてcheckerいるかどうかをアサートしtable_rowます。しかし、このことはすべて重そうに見え、（おそらく）パフォーマンスに影響します。 「その方法を確認する」unittest 最後のテーブルスキーマを記憶し、テーブルが変更されるたびに失敗するunittestを作成するだけです。その場合、プログラマーは「exportメソッドをチェックアウトするのを忘れないでください」のようなものを見るでしょう。警告プログラマーを非表示にするには、問題をチェックアウトしexport、手動で（別の問題です）新しいフィールドを追加してテストを修正します。 私には他にもいくつかのアイデアがありますが、それらは実装するのが面倒で、理解するのが難しすぎます（そして、プロジェクトをパズルにしたくないのです）。 上記の問題は、私が時々遭遇するより広範なクラスの問題の例です。いくつかのコードやインフラストラクチャをバインドしたいので、それらのいずれかを変更すると、すぐにプログラマに別のコードをチェックするよう警告します。通常、一般的なロジックの抽出や信頼性の高い単体テストの作成などの簡単なツールがありますが、より複雑なケースのツールを探しています。

13 design  design-patterns  architecture  unit-testing 

次のようなS＃arpアーキテクチャを使用して実装されたCQRSパターンの一部があります。 public class MyCommand { public CustomerId { get; set; } // some other fields } public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult> { Handle(MyCommand command) { // some code for saving Customer entity return CommandResult.Success; } } なぜCommandデータと処理メソッドの両方を含むクラスを持たないのでしょうか？コマンド処理ロジックをコマンドプロパティとは別にテストする必要がある場合、一種のテスト容易性の利点ですか？または、さまざまな実装で1つのコマンドを処理する必要がある、頻繁なビジネス要件ICommandHandler<MyCommand, CommandResult>ですか？

13 c#  design-patterns  architecture  cqrs 

私は2か月前に6人の開発チームに参加しました。人々は素晴らしいです、すべてが良いです。しかし、私はますますアドホックな考え方を観察します。スタッフはすぐに修正されますが、将来の使いやすさを犠牲にして、テストはほとんどなく、2人の人が喜んで認めています。 これに対処するには？私は例を挙げてリードしたいと思いますが、時間は限られています-ものを設計し、実際に実装するのが好きです。しかし、私はアドホックな考え方が私に感染していることを恐れており、デザインとコードの明快さと単純さを追求するのではなく、それを確立するのは簡単ではありません部外者は分離することができます-スケジュールと管理のためだけに。

13 architecture  coding-style  management  technical-debt 

この質問は、アーキテクチャのベストプラクティスに関するものです。 現在のアーキテクチャ ユーザー情報のためにMySQLにアクセスするPHPクラスがあります。それを呼び出しましょうUser。 Userに何度もアクセスされるため、負荷を軽減するためにキャッシュのレイヤーを実装しました。 最初のレイヤーは、「リクエストごと」キャッシュと呼ばれるものです。MySQLからデータを取得した後、データをのプライベートプロパティに保存しますUser。データに対する後続のリクエストは、MySQLからデータを再リクエストする代わりにプロパティを返します。 Webリクエストはリクエストごとに存続および終了するため、このキャッシュは、アプリケーションが1回のリクエストでMySQLに複数回アクセスすることを防ぎます。 2番目のレイヤーはMemcachedです。プライベートプロパティが空の場合、最初にMemcachedでデータを確認します。Memcachedが空の場合、MySQLにデータを照会してMemcachedを更新し、のプライベートプロパティを更新しますUser。 質問 私たちのアプリケーションはゲームであり、いくつかのデータが可能な限り最新であることが不可欠な場合があります。約5分間で、ユーザーデータの読み取り要求が10回または11回発生する場合があります。その後、更新が行われる場合があります。後続の読み取り要求は最新である必要があります。そうしないと、ゲームの仕組みが失敗します。 そのため、データベースの更新が発生したときに実行されるコードを実装しました。このコードは、更新されたデータを使用してMemcachedのキーを設定するため、Memcachedへの後続のリクエストはすべて最新です。 これは最適ですか？このような「リビングキャッシュ」のようなものを維持しようとするとき、パフォーマンスの問題やその他の「注意点」を知っておく必要がありますか？

13 architecture  caching  memcached 

現在、いくつかの大きなWebベースのマルチテナント製品がありますが、すぐにテナント固有のカスタマイズが多数行われることがわかります。 あちこちの余分なフィールド、おそらく余分なページ、またはワークフローの途中の追加のロジック-そのようなこと。 これらのカスタマイズの一部は、コア製品に組み込むことができ、それは素晴らしいことです。それらのいくつかは非常に具体的であり、他の人の邪魔になります。 これを管理するためのいくつかのアイデアを念頭に置いていますが、どれもうまく拡張できないようです。明らかな解決策は、クライアントレベルの設定を多数導入し、クライアントごとにさまざまな「機能」を有効にすることです。それの欠点は、もちろん、非常に複雑で混乱していることです。本当に膨大な数の設定を導入でき、時間の経過とともにさまざまなタイプのロジック（プレゼンテーション、ビジネス）が手に負えなくなる可能性があります。次に、クライアント固有のフィールドの問題があります。これは、既存のテーブルに多数のNULL可能フィールドを追加するだけでなく、よりクリーンなものを要求します。 では、これを管理するために人々は何をしているのでしょうか？Force.comは拡張性のマスターのようです。明らかに、彼らは一からプラットフォームを作成し、それは超拡張可能です。WebベースのUIを使用して、ほぼすべてに追加できます。FogBugzは、実際にForceに触発された可能性のある堅牢なプラグインモデルを作成するのと似たようなことをしました。私は彼らがそれに多くの時間とお金を費やしたことを知っています。もし私が間違っていなければ、意図は将来の製品開発のために実際に内部で使用することでした。 構築したいと思われるかもしれませんが、おそらくそうすべきではないようです。:) プラガブルアーキテクチャへの大規模な投資が唯一の方法ですか？これらの問題をどのように管理し、どのような結果を目にしていますか？ 編集： FogBugzはかなり堅牢なプラットフォームを構築し、それを使用して画面をまとめることで問題を処理したかのように見えます。それを拡張するには、ISearchScreenGridColumnなどのインターフェイスを実装するクラスを含むDLLを作成し、それがモジュールになります。多数の開発者がいて、数か月間作業したことを考えると、構築するのに莫大な費用がかかったと確信しています。さらに、その表面積はおそらく私のアプリケーションのサイズの5％です。 現在、Force.comがこれを処理する正しい方法かどうかを真剣に考えています。そして、私はハードコアASP.Netの男なので、これは自分自身を見つけるのに奇妙な立場です。

13 asp.net  plugins  architecture 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 アーキテクトの地位にとってJava認定（SCJP、SCWCDなど）がどれだけ重要かを知りたい。Java開発の良い経験があり、アーキテクトレベルでのキャリアを追求したい人は、CVの認定が必要だと思いますか。彼が主任開発者の役割で働いたことがない場合はどうなりますか？ あなたが建築家の地位のために私のインタビューを行っている場合。そして、私は5年間の経験を持つさまざまなチームでJava Web開発者として働いてきました。決してリードしないでください。そして、私は履歴書に認定バッジを持っています。 開発者は、チームでアーキテクトになるためのキャリアパスをどのように作成できますか？

13 java  architecture 

共通の問題を共有する次の3つのプロジェクトがあります。 Webシステム上にロジックが必要であり、RESTful Webサービスを介してそのようなシステムと通信するローカルアプリケーション（POSなど）が必要です。 私のソリューション 私が思いついたソリューションは、デスクトップアプリケーションにメッセージキューを実装して、サービスがオフラインである間、より正確には非同期メッセージキューを操作を保存することです。しかし、それは簡単な部分です（もしそれが最良の解決策であるなら）。また、データの同期と競合の解決にも関心があります。 利害関係者によるレポートと監視にはWebアプリが必要であり、Webサービスは複数の施設の要求を処理するため、メインシステムはWebベースである必要があります。 デスクトップクライアント（できればシン）はJava（より具体的にはNetbeans）で実装され、WebシステムはSymfony2で実装されます。2つのプロジェクトにはクライアントのハードウェア統合が必要であるため、Webテクノロジー（Appcelerator Titaniumなど）を使用してデスクトップアプリケーションを作成することは大きな苦痛になる可能性があります。 私の質問 最小の労力で最大の効率を意味する、拡張可能な優れたソリューションとは何ですか（ローカル操作用にバックアップサーバーを購入するなどの追加コストは不要）。 他に誰がこれに対処しましたか？どのようにして問題を解決しましたか？どんな教訓を共有できますか？ 同期はどのように対処しましたか？ 編集：ポイント＃3で私の質問に不足している部分を追加しました

13 java  php  architecture  web-services 

サーバーのクラスターで一度だけ実行したいタスクがある場合、定期的にこれを達成するための最良の方法は何ですか？この場合のクラスターの定義は、ロードバランサーの背後に分散セッションを持つ2つ以上の同一サーバーです。 使用例： X時間に1回のみ実行する必要がある実行コストの高いタスクがあります。このジョブは、たとえば多数のレコードを反復処理し、そのステータスを更新できます。 最悪のシナリオは、ジョブを2回実行するとデータが無効になることです。 最良のシナリオは、ジョブがすべてのサーバー上のリソースを利用することです。 要件の概要： ノードの1つがダウンしている場合でも、ジョブを実行する必要があります。 ジョブは、スケジュールごとに1回のみ実行する必要があります。 複数のジョブが同時にまたは重複してスケジュールされている場合、実行中のジョブの数はサーバー間で均等に分散されます。 マシンは同じコードベースを持ち、NTPを介して同期する必要があります。 環境変数によって、構成はノードごとに異なる場合があります。 ジョブは時間どおりに、または割り当てられた時間の特定の間隔内で開始する必要があります。（たとえば5分と言います） 可能な解決策 1つのノードをマスターノードとして設定します。上記1に違反するため、これは機能しません。 ロードバランサーのバランスを取り、ジョブを開始するよう要求します。残念ながら、これには、同時に複数のジョブを実行している場合、それらがすべて同じマシンで実行されるという副作用があります。 これは、Javaのサーブレットコンテナで実行する必要があります。しかし、それは私が探している仕事をコーディングしていません。 確かにこれは既知の最良の解決策を備えた解決された問題です。 関連する質問。 /programming/5949038/schedule-job-executes-twice-on-cluster 上記の5つの要件に従ってソリューションが不十分であるため、これは重複ではありません。最も投票されたソリューションは人種問題に苦しみ、2番目のソリューションは要件3に違反します

13 language-agnostic  architecture  scheduling