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

リポジトリを実装します。リポジトリのコンシューマは複数の操作を実行でき、一度にコミットしたいので、UOWパターンを使用したいと思います。 問題に関するいくつかの記事を読んだ後、他の方法で行われている記事によっては、この2つの要素を関連付ける方法がまだわかりません。 UOWはリポジトリの内部にある場合があります。 public class Repository { UnitOfWork _uow; public Repository() { _uow = IoC.Get<UnitOfWork>(); } public void Save(Entity e) { _uow.Track(e); } public void SubmittChanges() { SaveInStorage(_uow.GetChanges()); } } そして時々それは外部です： public class Repository { public void Save(Entity e, UnitOfWork uow) { uow.Track(e); } public void SubmittChanges(UnitOfWork uow) { SaveInStorage(uow.GetChanges()); …

17 design-patterns  architecture  unit-of-work  repository-pattern 

私は同僚のためにシングルトンを介した依存性注入の使用について聞いてきました。互いに置き換えることができる2つの直交パターンであるかどうかはまだわかりませんか？または、DIはシングルトンパターンをテスト可能にする方法ですか？ 次のコードスニペットをご覧ください。 IMathFace obj = Singleton.Instance; SingletonConsumer singConsumer = new SingletonConsumer(obj); singConsumer.ConsumerAdd(10,20); SingletonConsumer型のパラメータを受け入れていますIMathFace。内部的にシングルトンクラスにアクセスする代わりにSingletonConsumer、呼び出し元から渡されたシングルトンインスタンスを取得します。これは、依存性注入を介してシングルトンクラスを使用する良い例ですか？

17 c#  architecture  singleton 

新しいプロジェクトを紹介したばかりの場合、その仕組みを理解するために最初に探すことは何ですか？ 最初にデザインを探しますか？デザインがある場合、その中で何を探しますか？クラス図または展開図またはシーケンス図または他の何か？ それとも、コードにまっすぐ行きますか？もしそうなら、異なるレイヤーがどのように相互作用するかをどのように理解しますか？

17 design  architecture 

現在、サーバー上の複数のREST Webサービスと通信するリッチJavaScriptクライアントに基づいた新しいWebアプリケーションを開発しています。そのアプリケーションは、異なる言語を持つ少なくとも2つの国で使用することを目的としているため、ローカライズする必要があります。 私の質問は、ローカライズをどこで管理する必要があるかということです。RESTサービスは、ローカライズされたデータを使用してリクエストを受信し、回答を送信する必要がありますか？

17 architecture  javascript  web-applications  localization 

プロジェクトの単体テストと統合テストを作成する必要があります。 すべてのテストを単一のテストフォルダーに入れる必要がありますか？ または、単体テストと統合テストをそれぞれ個別のテストフォルダーに配置する必要がありますか？ それとも、それらを別々のプロジェクトに入れるべきですか？ それらをまとめると、このアプローチには利点や欠点がありますか？

17 architecture  unit-testing  integration-tests 

職場では、2年近く開発中の大規模な内部アプリケーションがあります。私は最近プロジェクトに参加しましたが、アーキテクチャの一部には少し困惑しているので、建築家に同じ質問をする前にここの誰かがアドバイスを提供できることを願っています）。 以下が少し長い場合は申し訳ありませんが、質問する前にシステムが何であるかをよく描きたいと思います:) システムのセットアップ方法は、1つのメインWebアプリケーション（asp.net、AngularJS）があり、ほとんどの場合、他のさまざまなサービスからのデータを集約するだけです。したがって、基本的には、AngularJSアプリケーションのホストです。文字通り、クライアント側をブートストラップする1つのMVCコントローラーがあり、他のすべてのコントローラーはWebAPIコントローラーです。 クライアント側からの呼び出しは、これらのコントローラーによって処理されます。これらのコントローラーは、Webアプリケーションをホストするだけのボックスに常に展開されます。現在、このようなボックスが4つあります。 ただし、呼び出しは最終的にさらに別のWebAPIアプリケーションのセットにルーティングされます（通常、これらはセキュリティ、顧客データ、製品データなどのビジネスエリアごとです）。これらのWebAPIはすべて、専用のボックスにも一緒にデプロイされます。また、これらのボックスが4つあります。 1つの例外を除き、これらのWebAPIは組織の他の部分では使用されません。 最後に、これらのWebAPIは「バックエンド」サービスをさらに別のセットで呼び出します。これは通常、さまざまなERPシステムおよびデータストア（制御不能）の上に置かれたレガシーasmxまたはwcfサービスです。 アプリケーションのビジネスロジックのほとんどは、これらのWebApiにあります。たとえば、レガシーデータの変換、集約、ビジネスルールの実行など、通常のタイプのものです。 私が混乱しているのは、WebApplicationと、それを提供するWebAPIをこのように分離することで得られる利点の可能性です。他の誰もそれらを使用していないため、スケーラビリティの利点はありません（つまり、APIサーバーの負荷の増加はWebサーバーの負荷の増加を意味するため、別の4つのAPIボックスを追加しても負荷はありません）したがって、WebサーバーとApiサーバーの比率は1：1でなければなりません） また、ブラウザ=> HTTP => WebApp => HTTP => WebAPI => HTTP =>バックエンドサービスを追加のHTTP呼び出しを行う必要があるという利点もまったくありません。（WebAppとWebAPI間のHTTP呼び出しが私の問題です） そのため、現在は、現在のWebAPIを個別のソリューションから、WebApplicationソリューション内の個別のプロジェクトに移動し、間に単純なプロジェクト参照と単一の展開モデルを配置することを検討しています。したがって、最終的にはクラスライブラリになります。 展開に関しては、これは4 + 4ではなく8つの「フルスタック」Webボックスがあることを意味します。 新しいアプローチのメリットは次のとおりです。 WebアプリケーションとWebAPIサーバー間のシリアル化/逆シリアル化のサイクルが1つ少ないため、パフォーマンスが向上します。 WebアプリケーションサーバーとWebApiサーバーのそれぞれの発信境界と着信境界のDTOとマッパーに関して削除できる（つまり、メンテナンス/テストする必要がない）大量のコード。 意味のある自動化された統合テストを作成する能力が向上しました。バックエンドサービスを単純​​にモックし、中間層のHTTPジャンプの混乱を回避できるからです。 だから質問は：私は間違っていますか？WebApplicationボックスとWebAPIボックスを分離したという基本的な「魔法」を見逃していませんか？ 私はいくつかのN-Tierアーキテクチャの資料を調査しましたが、状況に具体的な利益をもたらすことができるものを見つけることができないようです（スケーラビリティは私が知る限り問題ではなく、これは内部アプリなのでWebAPIアプリケーションに関するセキュリティは問題になりません。） また、システムを提案されたセットアップに再編成した場合、メリットの点で何が失われますか？

16 architecture  asp.net  enterprise-architecture  n-tier 

私は、数十のデータベーステーブル（集計、エンティティ/値オブジェクト）を使用する比較的複雑なアプリケーションで作業し、DDDを適用しています。この時点では、基本的にDDD-Liteのように見えます。つまり、アプリケーション/ドメインサービス、ドメインモデル（エンティティ、値オブジェクト）、およびリポジトリがあります。 私はDDDの実装という本を取り上げましたが、彼が最初に言及しているのは、DDDを開始するときによくある最初のミスとして、DDD-Liteおよびバウンドコンテキストとドメインイベントが欠落していることです。 現在、集計リレーションシップによってドメインモデルを整理し、ネームスペースを使用してそれを実証しようとしました。 ドメインモデルプロジェクトを個別のバウンドコンテキストに（まだ）分離することに関連する利点/欠点が見当たりません。おそらくそれは後で明らかになるかもしれませんが、バウンドコンテキスト（およびサブドメインなどが結び付けられている場合は、サブドメインなど）に関する実際のフィードバックをお願いします。

16 architecture  domain-driven-design  enterprise-architecture 

フレームワークに「グローバルルートクラス」アプローチをもたらす利点は、私にとって非常に興味深いものです。簡単な言葉で言えば、.NETフレームワークは、すべてのクラスに適した一般的な機能を持つ1つのルートオブジェクトクラスを持つように設計されました。 今日、私たちは内部使用のための新しいフレームワーク（SAPプラットフォームの下のフレームワーク）を設計しており、私たちは全員2つのキャンプに分かれています。 私は「グローバルルート」キャンプにいます。そして、そのようなアプローチが優れた柔軟性と開発コストの削減をもたらす理由は、一般的な機能をこれ以上開発しないためです。 そのため、どのような理由で.NETアーキテクトがそのような方法でフレームワークを設計するのか、本当に知りたいと思っています。

16 .net  architecture 

現在、技術的に複雑な製品がほとんどない中小企業で働いています。私はそれらの1つの唯一の開発者です。約1年前、私は製品のレガシーバージョンを入手し、それを「サポート」し始めました。 顧客は、そのような種類の新機能、ビジネス価値などについてのみ話します。問題は、コードはC＃ですが、非常に手続き的なことです。抽象化はありません。クラスはVisual Studioで必要な場合にのみ使用されます-たとえば、フォーム。これらのクラスの実装は本当にひどく、コードの保守は本当に困難です。 これらすべての年の間、私はリファクタリングのために自分の時間を費やしています。最新バージョンでは、かなり抽象化などがあります。多くのコンポーネントをゼロから再実装する必要がありましたが、これらのコンポーネントに新しい機能を追加したり、動作を変更したりするのは、他のコンポーネントよりもはるかに簡単だと思います。 問題は、私が自分の時間を過ごすことです。結果は本当に気に入っていますが、1日12時間働くのは好きではありません。同様の状況に行ったことはありますか？何を試せばいいですか？私はすでにそれを議論しようとしましたが、まだ成功していません。 レガシーコードに多くの変更を必要とする新機能を実装することに決めた瞬間が怖いだけです。それは顧客に衝撃を与える可能性があります。これらのアイコンを変更するのになぜ8時間かかるのですか？顧客は、コードに500箇所の変更が必要であることを気にしません。また、これらの500か所すべてを最初に見つける必要があります。 何か案は？

16 architecture  customer-relations 

「高度に結合された」という用語はよく知っていますが、コードが高度に結合されていることを示す兆候（コードのにおい）があるかどうかは興味があります。現在、Java EEを使用していますが、これはどの言語にも適用できます。 編集： 誰もが興味を持っている場合、この記事は参考になります。（IBM）

16 architecture  code-smell 

データベースを操作しながら、ユニットのテストを可能にするOOP戦略にはどのようなものがありますか？Userクラスがあり、本番環境がMySQLに対して機能しているとします。PHPを使用してここに示す2つの可能なアプローチがあります。 load()およびのインターフェイスで$ data_sourceを渡し、save()データのバックエンドソースを抽象化します。テスト時には、別のデータストアを渡します。 $ user = new User（$ mysql_data_source）; $ user-> load（ 'bob'）; $ user-> setNickname（ 'Robby'）; $ user-> save（）; データベースにアクセスし、結果行をユーザーのコンストラクターに渡すファクトリーを使用します。テスト時には、$ rowパラメーターを手動で生成するか、UserFactory :: $ data_sourceでオブジェクトをモックします。（変更をレコードに保存するにはどうすればよいですか？） class UserFactory { static $data_source; public static function fetch( $username ) { $row = self::$data_source->get( [params] ); $user = new User( $row ); return $user; …

16 architecture  unit-testing  object-oriented  database 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 あまり関係のない理由で、私はDelphi 7をこのような長い時間でもう一度インストールしました。私は言わなければならない、私は完全に吹き飛ばされた-私はかなりしばらくの間ではなかった方法で。これは私が物事を覚えている方法ではありません。インストールには約30秒かかりました。起動には2秒かかり、すぐに使用できました。開始後、2番目に「実行」を押すと、1秒以内に空のプログラムが既に表示され、実行されています。コンピューターの速度が大幅に向上しました！ しかし、私がこのように吹き飛ばされた理由は、通常私はVisual Studio 2010を使用しているためです。確かに、デルファイ7は、Visual Studio 2010よりもはるかに小さいシステムであるが、それは持っている外観がすべて本当に必要なものを持っていることの：コントロールパレット、フォームデザイナ、コード補完とコードエディタを。言語がよりシンプルで、コード補完のパワフルさが少なく、IDEの拡張性や機能が豊富ではないかもしれないことを理解していますが、それでも：（どのメカニズムを介して）どのように機能するのかわかりません多くの追加機能（まだトリガーしていなかったかもしれません）により、Visual Studioのようなシステムは常に比較して低迷します。 システムの操作に経験のある人にVisual Studioの規模を聞いてみたいと思います。それが遅くなる原因は何ですか？コードベースを人間の理解能力の範囲内に保つために必要な抽象化のレイヤー上のレイヤーですか？実行する必要があるコードの量は膨大ですか？それは、クロックサイクル/メモリ使用部門の（驚くほど巨大な）費用で、プログラマの時間節約アプローチに向かう現代の傾向ですか？

16 architecture  performance 

アプリケーションを構築しているとき、これが特定の機能を実行または実装する最良の方法であるかどうかを常に問いかけています。多くの場合、パフォーマンスに関する「馬の前にカートを置く」べきではないというコメントを受け取るために、stackoverflowまたはフィードバックを希望する別のフォーラムに質問を投稿します。ほとんどのプログラマーは、アプリケーションが終了するまでパフォーマンスについて本当に考えないのでしょうか、それともパフォーマンスがまったく許容できないのでしょうか?? つまり、開発環境は本番環境とは異なり、開発用ラップトップからの結果に完全に依存するべきではないことを理解しています...しかし、他のものよりも優れたパフォーマンスをもたらすプラクティスとテクニックがあります。 開発プロセス全体でパフォーマンスを考慮することは悪い習慣ですか？パフォーマンスが実際に低下するまで、これらの考慮事項をオフにする必要がありますか?? 更新 明確にするために、機能の一部を検討している、または作業しようとしている状況について説明しています。実装にはいくつかの方法がありますが、各実装がどの程度拡張できるかはよくわかりません。また、よく知らないテクニックもいくつかあります。小規模ではいずれのアプローチでもおそらく適切ですが、大規模では一部のアプローチが維持され、一部は維持されません。多くの場合、私が意見やガイダンスを求めるとき、応答は次のとおりです。後で心配する...

16 design  architecture  performance 

私は最近マイクロサービスについて多くのことを読んでいますが、これまでに得た結論のいくつかを以下に示します（私が間違っている場合は修正してください）。 マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。 マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとB は実際には1つのマイクロサービス/ BCである必要があります。 マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。 サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。 マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。 マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。 マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。 このアーキテクチャについての私の理解を確認する以外に、質問の他の部分は主にサービスの発見に関連しています。サービスが非同期で通信しており、Amazon SQSのような中央イベントキューを使用している場合、そのようなアーキテクチャではサービスディスカバリーがその場所にないということですか？ サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

15 architecture  domain-driven-design  soa  microservices 

Clojureなどの関数型プログラミング言語への（明らかに限定された）経験から、データのカプセル化はそれほど重要ではないようです。通常、マップやセットなどのさまざまなネイティブタイプは、オブジェクトよりもデータを表すための優先通貨です。さらに、そのデータは一般に不変です。 たとえば、この件に関するインタビューで、Clojureの名声のRich Hickeyからの有名な引用の1つを次に示します。 Fogus：その考えに従うと、Clojureがそのタイプでデータ隠蔽のカプセル化を行わないという事実に驚く人もいます。なぜデータ隠蔽をやめることにしたのですか？ ヒッキー：Clojureがプログラミングを抽象化に重点を置いていることを明確にしましょう。ただし、ある時点で、誰かがデータにアクセスする必要があります。また、「プライベート」という概念がある場合、それに対応する特権と信頼の概念が必要です。そして、それは非常に多くの複雑さと小さな価値を追加し、システムに硬直性をもたらし、しばしば物を本来あるべきでない場所に住まわせます。これは、単純な情報がクラスに入れられるときに発生する他の損失に追加されます。データが不変である限り、誰かが変更される可能性のあるものに依存するようになる可能性があることを除いて、アクセスを提供することによってもたらされる害はほとんどありません。まあ、大丈夫、人々は実際の生活の中で常にそうしていて、物事が変わると適応します。そして、それらが合理的であれば、彼らは、将来変化する可能性のある何かに基づいて決定を下すときを知っています。だから、それはリスク管理の決定であり、プログラマは自由にすべきだと思う。抽象化に向けてプログラミングを行い、実装の詳細と結婚することを警戒したいという感覚がなければ、優秀なプログラマーになることは決してありません。 オブジェクト指向の世界から来て、これは私が長年にわたって学んだ神聖な原則のいくつかを複雑にするようです。これらには、情報隠蔽、デメテルの法則、統一アクセス原則などが含まれます。カプセル化という一般的なスレッドにより、他の人が触れてはいけないことを知るためのAPIを定義できます。本質的に、一部のコードのメンテナーがコンシューマーのコードにバグを導入する可能性を心配することなく、自由に変更やリファクタリングを行えるようにするコントラクトを作成します（オープン/クローズ原則）。また、他のプログラマーがそのデータを取得または構築するために使用できるツールを知るための、クリーンで精選されたインターフェースを提供します。 データへの直接アクセスが許可されると、そのAPIコントラクトは壊れ、カプセル化の利点はすべてなくなるようです。また、厳密に不変のデータは、ドメイン固有の構造（オブジェクト、構造体、レコード）の受け渡しを、状態とその状態で実行できる一連のアクションを表すという意味であまり役に立たないようです。 APIを定義する必要があり、多くの開発者がシステムの特定の部分の操作に関与するなど、コードベースのサイズが巨大になったときに発生するように思われるこれらの問題に、機能コードベースはどのように対処しますか？これらのタイプのコードベースでこれがどのように処理されるかを示すこの状況の例はありますか？

15 object-oriented  architecture  functional-programming