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

ドメイン駆動設計（DDD）を研究する際に、サブドメインの概念に出くわしましたが、まだ理解していないと思います。これについて私の最初の理解は、サブドメインがアプリケーションのドメインのサブセットであるということでした。言い換えれば、それは問題空間のパーティションです。サブドメインには3つのタイプがあると読みました。 コアサブドメイン サポートするサブドメイン 汎用サブドメイン。 私の理解はこのようなものでした。アプリケーションのドメインを選択しましたが、それは非常に複雑です。次に、それを見て、それをより単純な部分に分割する方法を見つけます。その一部はコアサブドメインであり、一部はサポートするものであり、その他は一般的なものです。 詳細情報を検索したところ、別のことを言っている人が見つかりました。コアサブドメインが1つだけ存在し、いくつかの汎用サブドメインがあり、サポートサブドメインがまったくないことです。 だから私の質問は： 本当にサブドメインとは何ですか？私の最初の理解は正しいものですか、それとも私が読んだ2番目のものですか？ このサブドメインの考え方はどのように役立ちますか？ サブドメインを識別するための良い基準は何ですか？このアイデアをより有効に活用するためにサブドメインを決定するとき、何を念頭に置く必要がありますか？ 編集：もう少し検索すると、次のことがわかりました： eコマースシステムについて考えてみましょう。最初は、それがショッピングコンテキストのアプリケーションであることがわかります。さらに詳しく見ると、在庫、配送、アカウントなど、他のコンテキストもあることがわかります。 これは、私が最初にサブドメインだと思ったものです。ドメイン（ショッピングドメイン）を選択し、それをより単純なサブドメイン（在庫、配送、アカウントなど）に分割します。しかし、問題のテキストでは、彼らはこれらを文脈と呼んでいます。私の以前の理解はサブドメインではなくコンテキストですか？ このサイトで、サブドメインと制限付きコンテキストの違いについて1つの質問を見つけました。答えは、サブドメインは問題空間のパーティションであり、コンテキストは解空間のパーティションであると述べています。ただし、ショッピングコンテキストを在庫、配送、アカウントなどに分離することは、概念的な区分ではありません。つまり、解空間ではなく問題空間にありますか？

8 architecture  domain-driven-design 

背景： 同僚と私はMVCの解釈が異なります。つまり、同じ問題を考えると、根本的に異なる解決策が考えられます。彼はJavaのバックグラウンド出身で、MVCのすべてのコンポーネントが伝統的にオブジェクトをモデル化している可能性があります。私はHaskellのバックグラウンド出身で、OOPの経験はほとんどありません。 問題空間： モデル化しようとしている問題は、デスクトップ環境に少し似ています。ユーザーセッション（おそらくユーザーのログイン、デスクトップの背景）とデスクトップ上のプロセス（iTunes、Finderなど）には、それぞれ独自のモデルプロパティ（最小化など）があるという概念があります。 次の点に同意します。HMVCが最も優れた表現であると考えています。Session（デスクトップ）とProcess（アプリケーション）の2つのMVCオブジェクトがあること、およびProcessの概念Sessionやバックリンクを必要としないことに同意します。 ただし、MVCの中心的な意味と、ユーザーのデスクトップ上のプロセスのリストを保持する場所にどのように影響するかについては、意見の相違があります。 彼の解釈： 彼は伝統的にコードやレンダリングシステムで簡単にモデル化できる非常に有効なポイントを主張しています。彼は、プロセスのリストはProcessControllerオブジェクトのリストである必要があり、SessionControllerその中にモデルが個別のオブジェクトとして内部に含まれていると述べています。状態の、かなりの量の両方の中にあることをこれは意味SessionControllerし、SessionModelどのように関連しているSessionViewレンダリングする必要があります。 これは、簡単な検索でインターネット上で読み取ることができたものと非常に調和しているようです。 私の解釈： 私の解釈は最大のアーキテクチャ変更を必要とし、コードでの実装は難しいようですが、概念的には正しいと思います。なぜこれが当てはまらないのか、またはこの解釈と一致する別のモデル（MVCでない場合）を提示し、両方のパターンの長所と短所を強調して、最も情報に基づいた決定を下せるように誰かに説明してほしい（どちらも持っていない）ソフトウェアアーキテクチャの強力な背景）。 ：私は3つの交換部品とトライアドとしてMVCを参照してくださいModel、ControllerとView。これは、私がインターネット上で読むことができるものと一致し、一部のソースは、「同じインターフェースを持つビュー、コントローラー、およびモデルは、異なる効果に交換可能である必要がある」のようなものに沿って物事を言うでしょう。これが機能すると想像する方法は次のとおりです。 モデルを交換すると、データの検証または保存の方法が変わります コントローラを交換すると、ページの動作が変更されますが、ページの一般的なデータコンテンツを変更する可能性があるものは変更されません ビューを交換すると、ページの表示方法が変わります このことから、私は任意の与えられたことを推論Modelし、Viewコントローラだけで行動していないページの「内容」を変更する必要があるため、唯一のコントローラはデータにページを変更しないでくださいスワッピング最初にレンダリングします。これは、鉄道システムの「駅コントローラー」としてのコントローラーの概念的な視覚化、モデルとしての鉄道の計画、および実際の物理的な外観とトラックの外観/感触（異なるフレーバーでは、「ビューとして「リアル」または「バーチャル3D」）。 ここで私たちは反対します： でユーザーに表示されるデータSessionViewはデスクトップ上のさまざまなプロセスによって変更されるため（プロセスは関連データとしてモデル化しています）、にSessionModelはのインスタンスのリストが含まれているはずですProcessModel。つまりSessionController、同じでランダムを使用すると、SessionView概念的に同じデータ（デスクトップ上のプロセス）が表示されるはずです。 彼は、Model別のモデルについて決して知らない方がより意味があると主張しています。つまり、SessionControllerにはのリストがProcessControllerあり、各Controllerオブジェクトにはそのモデルへのリンクがあります。a SessionViewが同じSessionModelでも異なるSessionController場合、ユーザーに表示されるデータは根本的に異なるはずです。 それぞれの解釈について議論し、最も十分な情報に基づいた結果に到達するために私たちを助けてください。 御時間ありがとうございます！

8 design  object-oriented  architecture  mvc  hierarchy 

この本の382ページに、（エンティティの）ルートの下で、値オブジェクトを集計で使用することについて説明している箇所があります。Product他の値に加えて、エンティティのSet<ProductBacklogItem>コレクションが含まれている例があります。 さて、バーノンはProductBacklogItemエンティティが値オブジェクトではなく、なぜであるかを説明しようとします： ProductBacklogItemが値ではなくエンティティとしてモデル化されるのには、十分な理由があります。値オブジェクト（6）で説明したように、バッキングデータベースはHibernateを介して使用されるため、値のコレクションをデータベースエンティティとしてモデル化する必要があります。要素のいずれかを並べ替えると、かなりの数、またはすべてのProductBacklogItemインスタンスが削除されて置き換えられる可能性があります。これは、インフラストラクチャに大きなオーバーヘッドを引き起こす傾向があります。エンティティーとして、製品所有者が必要とする頻度で、すべてのコレクション要素にわたって順序付け属性を変更できます。ただし、MySQLでのHibernateの使用からKey-Valueストアに切り替える場合は、代わりにProductBacklogItemをValueタイプに簡単に変更できます。Key-Valueまたはドキュメントストアを使用する場合、 リポジトリの実装で、モデルがエンティティオブジェクトまたは値オブジェクトになるかどうかを判断する理由がわかりません。Key-Valueストアに行く場合でも、彼が話している順序が残っている可能性があります。 これは理にかなっていると思いますか？

8 architecture  domain-driven-design 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 始める前に、先取りの謝罪をする必要があります。 この投稿で使用している用語や語彙の一部が明らかに間違っている可能性が非常に高いため、重要な側面の一部を完全に誤って解釈している可能性もあります。私はこれが初めてなので、批判的になりすぎないでください。建設的なフィードバックを歓迎します。;） バックグラウンド 現在、200名の開発部門をマルチメソッドから「アジャイル」に移行しています。理由、理由、長所、短所は、この質問の範囲をはるかに超えています。 この開発部門には、正式に「ソリューションアーキテクト」と呼ばれる10人で構成されるアーキテクチャサービスチームが含まれています。実際には、それらはソリューションだけでなく、プロジェクトのすべての技術アーキテクチャ面（つまり、ハードウェア、ソフトウェア、セキュリティ、ガバナンスなど）をカバーする技術者です。また、開発チームに特別な機能（コードレビュー、標準ガイダンスなど）と幅広いビジネス（入札への技術的インプット、顧客の要件の事前契約技術プレビュー）を提供します。 この移行の一環として、私は、建築サービスチームが責任を負う作業活動を把握するために、かんばんボードを作成する任務を負っていました。開発/コーディングチーム用の無数のサンプルボードがありますが、アーキテクチャ用に見つけることができるものはありません。だから私は様々なソースから取って「何か」を作成しました、それについての真のフィードバックを本当に感謝します。 また、これは開始点/進行中の作業としてチームに提示されることにも注意してください。それは彼らのボードであり、私は彼らにそれを所有してほしいと思っています。 これまでのところ私はこのようなものを持っています メインボード メインボードは、すべてのアクティブ/バックログプロジェクトを保持する場所です。すべてのアクティブな作業はこのボードで行われます。これは、毎日の建築スクラムで簡単にレビューされ、毎週の終わりにさらに詳細なレビューが行われます。 ------------------------------------------------------------------------ | Evaluation | Implementation | Ad- Hoc | | Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done | ------------------------------------------------------------------------------- Person | | | | | | | …

8 architecture  agile  kanban 

複数のウェブサイトでデータを共有するためのシンプルなシステムを開発しようとしています。それらのほとんどはPHPで開発されていますが、一部はWordpress / Drupalで開発されています。冗長な情報が複数のWebサイトに分散しているため、複数のWebサイトで情報を個別に更新する必要があるという問題が発生しています。 静的なページでも共有データを取得できるソリューションを提供しようとしています。これが私の提案するアーキテクチャです： 私はこれを学術機関のために行っています。データは、単純な料金体系から学問的な方針までさまざまです。たとえば、学費を考えてみましょう。 学費-> ug、卒業生、薬局...各学部には、キャンパス外、キャンパス内、通勤者ごとに分類された料金体系があります。 "Undergraduate": { "metaid": "0770", "Offcampus": { "FeesItems": { "comprehensive": { "label": "Comprehensive Fees", "value": "2,141" } } } } moustacheを使用するフロントエンドの場合、jsを含めて、以下のような値を取得して値を取得するだけです。 <td>{{Undergraduate.Offcampus.FeesItems.comprehensive.label}} </td> <td>{{Undergraduate.Offcampus.FeesItems.comprehensive.value}}</td> 私の質問： このデザインはスケーラブルですか？ データ所有者にデータを編集する権限を与える方法は？ SQLにデータを保存する方法は？

8 architecture  json 

この記事では、フロントエンドコードを整理するために取り組んできました。BEM / SMACSSの記事を参照し、次に他の記事を参照します。 私は本当にベストプラクティスが何であるかを理解しようとしています...私はこの "標準"を決定するために数日を持ち、それから高優先度/高可視性/限られたタイムラインプロジェクトを実行する必要があります。そのため、アプリと同じように拡張できる基盤から始めたいと思います。 segment... という名前のコンポーネントがあるとすると、segments1ページあたり最大10 個のページが作成されます。それぞれsegmentが同じ基本クラスを共有します。ただし、特定のものsegmentsには修飾子があります（異なる背景色）。さらに、（BEMアプローチの）各ブロック内の要素にも修飾子があります。実例を示すために、ここに簡単な実装を示します（単一の要素のみで、arrowサイト全体にはそれぞれ4〜5個の要素がありますsegment）。 .segment__arrow { position: absolute; bottom: -24px; left: 50%; margin-left: -11px; background-position: center no-repeat; height: 21px; width: 21px; z-index: 2; } .segment__arrow--orange { @extend .segment__arrow; background-image: url('/images/arrow_orange.png'); } .segment__arrow--white { @extend .segment__arrow; background-image: url('/images/arrow_white.png'); } したがって、これは単一クラスのアプローチです。 <div class="segment__arrow--white"> ... </div> または、マルチクラスアプローチを使用することもできます。 .segment__arrow { …

8 architecture  css  scalability  front-end 

私は以前から、さまざまな規模のクライアントを抱えるコンサルティング会社で働いており、非常に単純なものから複雑なものまで、さまざまなWebアプリケーションを見てきました。 MVC サービス層 EF DB 本当に複雑に： MVC うわー DI / IoC リポジトリー サービス UIテスト ユニットテスト 統合テスト しかし、スペクトルの両端で、品質要件はほぼ同じです。単純なプロジェクトでは、新しい開発者/コンサルタントは、何が起こっているのかを理解するために6層の抽象化をたどる必要がなく、複雑な抽象化を誤解し、コストを下げるリスクを冒すことなく、期待に応え、変更を加え、すぐに貢献できます。 すべての場合において、実際にコードをスワップ可能または再利用可能にする必要はありませんでした。また、要件が変更されたため、テストが実際に最初の反復を超えて維持されることはありませんでした。 だから-最終的に- テストとインターフェースは使用されません 迅速な開発（読み取り：コスト削減）が優先事項 プロジェクトの要件は開発中に大きく変化します ...エンタープライズクライアントに複雑な問題を解決するためであっても、超シンプルなアーキテクチャを推奨するのは間違っているでしょうか？エンタープライズソリューションを定義するのは複雑ですか、それとも信頼性、同時ユーザー数、保守の容易さ、またはこれらすべてですか。 私はこれが非常に曖昧な質問であることを知っており、どの回答もすべてのケースに当てはまるわけではありませんが、私はしばらくの間ビジネスに携わっており、これらのさまざまな程度の複雑さで機能している開発者/コンサルタントからの連絡に興味があります、少なくともプロジェクトの開発中は、クールだが高価な抽象化が全体的なコストに見合うかどうかを聞くため。

8 web-development  design-patterns  architecture  freelancing 

[ SOユーザー（10k SO +）の提案でここに移動] ピアツーピアアプリケーションを開発したいのですが。私はLOBアプリで多くの経験を積んでいますが、P2Pアリーナは初めてです。 私は物事がどのように機能するかについて大まかな考えを持っていますが、私の理解を記入するためにいくつかの詳細が必要です。 私が知っている（信じる）必要なこと： かなりの割合のクライアントがインバウンド接続を有効にする必要がある（ala uPnP / NATルール） 特定のノードがダウンした場合に回復力を提供するために、ノードは他の既知のノードを共有する必要があります 任意のクライアント間でデータを送信するには、何らかの形式の同期/ルート検索が必要です 「ダム」クライアントとノードリストの同期/共有を処理し、メッセージをリレーするためのより強力な「スーパーノード」を区別するためのリソーススニッフィング インバウンドサポートのないクライアントは、接続するノードの情報を受信できるアウトバウンド接続を開いたままにする必要があります。 つまり、特定の中央サーバーへの接続に依存しないチャット/メッセンジャーサービスを（最初は）提供したいと思っています。物事を始めるには（または大幅なアップグレード後に）集中型の「スーパーノード」をいくつか用意する必要があると思いますが、機能するP2Pネットワークが確立されたら、これらはオプションにする必要があります。 私は多くの問題を見ることができ、それらに対処する方法がわかりません。主にどのように... 中央の権限を確認することなく、ユーザーを他のノードに認証する どのノードが他のどのノードについて知っているかを調整します（最小-最大数/レイテンシ別????） 特定のユーザーが別のユーザー（またはノード）がオンラインかどうかを判断できるようにする ノードの2つのグループが物理的に切断（エアギャップ）されている状況と、グループの再接続時に再同期する方法に対処する など 私はこれがかなり自由回答式の質問であることを知っているので、高レベルの設計パターンは高く評価されますが、私が本当に探しているのは、他の人がこれらの問題を処理する方法に関するまともなガイドです（そして私はまだ検討していません） ）。

8 .net  architecture  client  p2p 

1つのサービス内に2つのリポジトリを持つ方法は正しいですか？それはアプリケーションまたはドメインサービスですか？ Passport（政府ID）オブジェクトを含むべきPassengerオブジェクトがあるとします。PassengerRepositoryからPassengerを取得しています。PassengerRepositoryはサーバーへのリクエストを作成し、受信したデータを解析してリポジトリ内に保存するよりもデータ（json）を取得します。 PassportをEntityとして保存してPassportRepositoryに置きたいのですが、パスワードに関するすべての情報に、上記で受け取ったものよりもjsonの内部が含まれているため、混乱しました。 removePassport, addPassport, getAllPassengerなどのいくつかのメソッドでPassengerRepositoryとPassportRepositoryを含むPassengerServiceを作成する必要があると思います。 更新： したがって、より良い方法はPassportをVOとして表し、すべてのパスポートをPassenger集約内に格納することだと思います。ただし、別の質問があります。管理乗客のパスポートのメソッド（メソッドはサーバーAPIを呼び出す）をどこに置くべきですか。乗客の集合体のほうがいいと思います。

8 design  design-patterns  object-oriented  architecture  domain-driven-design 

Alistair CockburnのHexagonal Architectureについて興味を持って読んでいます。 彼の主張の1つは次のとおりです。 最後に、自動化された関数回帰テストは、ビジネスロジックをプレゼンテーションレイヤーから除外するという約束の違反を検出します。組織はロジックリークを検出して修正できます。 この点はわかりません。テストはヘッドレスであるため、UIレイヤーを呼び出すと例外がスローされると彼は言っていますか？それは非常に健全なテストではないようです！

8 architecture 

したがって、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を合わせており、工場にある私の部門（別の地理的な場所にある）もソフトウェア開発に対処する必要があります、しかしすべての製品にまたがるので、製品のソフトウェアの問題が原因でラインがダウンした場合にも迅速に修正できます。 つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。 地理的に分散していると、コア開発に参加するのが少し難しくなります（まあ、それはそれほど難しいことではないのですが、リモートで協力するということになると、意図しない文化的/政治的な障壁があるかもしれません） ）。 だから、私たちは現在、火を消しているだけで、ややアイドル/サブ活用されているので（新しい部門であるか、それが理由かもしれません）、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計の機会、および保守性とモジュール性の管理に関連する可能性のある他のすべての実装。他のグループは、時間がないため積極的な期限があり、コードの品質を損なうため、これに焦点を合わせていません（ソフトウェアプロジェクトの永遠の物語） 私のグループ/部門がこの役割を持つ管理職や他のグループによって公式に認識されることを望んでいるということです、そして私はこの問題のために私たちのグループの良い定義/アイデンティティを思いつくのに苦労しています。 だから私の質問は：この役割はすでに存在するものですか？または私はこのようなものを最初に作成したのですか？ 編集：つまり、すべてのリファクタリング作業を自分で行うのではなく、リファクタリングイニシアチブを推進するグループです。オープンソースコミュニティーとオープンソース製品のように、今考えてみると、

8 architecture  refactoring  maintainability  organization 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私は1年生向けにコース「プログラミング入門」を教えています。設計によって選択されたビット単位のデータ型サイズが特定の既知の制限または重要な値につながる興味深い例を見つけたいと思います。 ここではいくつかの例を示します。 Bellテレプリンターは7ビットコード（後でASCIIとして受け入れられる）を使用していたため、電子メッセージの添付ファイルを7ビットデータのみを含むようにエンコードすることがよくありました。 32ビットアドレス空間の従来の制限により、32ビットシステムで使用可能な最大4GbのRAMサイズと、FAT32で最大4Gbのファイルサイズが発生します。 データ型の選択（特にそのバイナリ長）が現代のITの世界にどのように影響したか、他に興味深い例をいくつか知っていますか。 コメントでいくつかの議論の後に追加されました： 制限を克服する方法を教えるつもりはありません。1バイトで-127..0 .. + 127 o 0..255の値を保持できること、2バイトで0..65535の範囲をカバーできることを彼らに知ってもらいたい。上記のbase64エンコーディングなど。基本的なデータ型を学習しているだけなので、これらの型の「大きさ」についての適切なリファレンスを見つけようとしています。

8 design  architecture  file-systems  data-types  32-bit 

拡張可能なWebアプリケーションをどのように実装しますか？私が考えているのは、プラグインサポートを提供するJenkinsやHudsonに似たWebアプリケーションです。プラグインを見つけてロードする方法は明らかですが、プラグインをアーキテクチャ全体に統合する方法はわかりません。特に以下の点については不確かです。 プラグインはどのようにビューを変更することができますか、例えばフォームに入力要素を追加しますか？ 私の最初のアイデアは、プラグインが特定のフォームのパーシャル/フラグメントを登録できるということです。 例：ユーザー登録ビューに表示される典型的なニュースレターチェックボックスフラグメントを登録するニュースレタープラグイン。 プラグインは着信要求にどのように反応しますか？ この場合も、直接的なアプローチは、特定の要求またはアクション（/ userへのPOST要求など）のリスナーを提供することです。 プラグインはどのようにしてデータを保持できますか？ これは、NoSQLデータストレージソリューションがリレーショナルデータベースよりも優れている状況であると想定しています。 拡張可能なWebアプリケーションに関して、コメント、アイデア、経験（デザインパターンもあるかもしれません）があれば幸いです。

8 design  architecture  web  jenkins  hudson 

人々は「3層（またはn層）アーキテクチャ」に従っているとしばしば主張し、時にはドメインモデルに切り替えると主張することもあります。しかし、私はこの神秘的な「3層アーキテクチャ」が何であるかを本当に理解したことがありません。正式な定義がないようです。ドメインモデルパターンを説明およびデモする参照や例は数多くありますが、3層への参照は、コードをUI、ビジネスロジック、およびデータアクセスレイヤーに分離することを示唆しています。そして、それは彼らが言うように見えるすべてです。 私が特に奇妙だと思うのは、ドメインモデルは、この3層のパラダイムを完璧に具現化したものだということです。ORMファイルとマッピングファイルはデータアクセスレイヤー、ドメインはビジネスロジック、UIはUIです。それではなぜ人々はそれが新しい何かであり、彼らが切り替えるべきものであるかのように話すのですか？ ドメインモデルを実装している人を見る前は、ほとんどのアプリケーションはUIであり、ロジックはUIとSPに分割されたストアドプロシージャにアクセスしていました。「UI」、「BLL」、「DLL」と呼ばれるいくつかのアセンブリが時々ありましたが、通常これらは単にUIとSP間のメディエーターであり、ロジックがランダムに分散するためのより多くの場所を残しました。 では、この神秘的な「3層」アーキテクチャとは何でしょうか。それは本当に存在していますか？もしそうなら、それがうまく実装されている例はどこにありますか？

8 architecture  domain-model  n-tier 

私の質問は、Stack Overflowでのこれと同様です。ビジネスレイヤー内で作業ユニット/リポジトリを使用する正しい方法は何ですか？ シナリオ： .Netソリューション DBからオブジェクトを取得するために使用されるIRepository IUnitOfWorkを使用して複数のリポジトリ間でトランザクションを許可 これは私には理にかなっていて、私はこれらの線に沿ってうまく機能する何かを実装しました。ここで、ビジネスロジックレイヤーを紹介したいと思いますが、3つの要素（BLL、UnitOfWork、およびリポジトリ）を整理することに頭が悩んでいます。 私の理解： リポジトリ-データの取得、操作 UnitOfWork-永続性 BLL-ビジネスに関連するロジック（「現実世界」）（その用語は嫌いです！） ASP.Net MVCフロントエンドがあるとします。 BLLはどのように見え、それを使用するMVCコントローラーはどのように見えますか？ 参考までに：私のIUnitOfWork / IRepository実装が私の混乱の根本的な原因であるのではないかと思います。 public class IRepository<T> { private IObjectSet<T> objSet; public IRepository<T>(IUnitOfWork uow) { objSet = uow.CreateObjectSet<T>(); } public IQueryable<T> Add(T entity) { objSet.Add(entity); } //etc. etc. for delete, attach, getall } したがって、BLLがある場合は、それをIUnitOfWorkに渡して、必要なIRepositoryインスタンスを作成できるようにする必要があるように感じます。しかし、BLL（フロントエンドとは別のDLL）は、ビルドするIRepositoryの実装をどのように「認識する」のでしょうか。

8 architecture  business-logic  unit-of-work  repository-pattern