問題タブ [onion-architecture]

私は現在、ドメイン駆動設計を研究しており、WPF プロジェクトに適用しようとしています。いくつかのチュートリアル ビデオを見て、次のような多くの記事を読みました。

• 同じレイヤーでのオニオン アーキテクチャの依存関係: インフラストラクチャと Web 通信
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• ドメイン駆動設計: ドメイン サービス、アプリケーション サービス

インターフェイスと制御の反転に焦点を当てていることがわかりました。いくつかの繰り返しレイヤー名があったことを読みました（知識の範囲を表すためのドメイン/コア、永続化のためのインフラストラクチャ、...のアプリケーション...私は理解していません）が、私が読んだ記事に応じて変化します。表示されないものもあります。

理論的には、すべてのニーズと問題に対処するためにオニオンアーキテクチャで必要なすべてのレイヤーのリストを、その意図 (どのようなコードが含まれているか、どのようなニーズを満たそうとしているか) とともに持つことは可能でしょうか? 、どのレイヤーを参照する必要がありますか)、お願いします。

私は DDD を使用するプロジェクトに取り組んでいます。いくつかのクラスがあり、それらをどこに置くべきかわかりません。

ドメインは既存のゲームに関するものです。このゲームには、キャラクター、スキルツリーなどの基本的な概念があります。私のドメイン クラスは、これらの概念を単純に表したものです。私はこのゲームを作りませんでした。

私のアプリケーション/プロジェクトは、これらの概念を表現するソフトウェアに付加価値を加えることです。現時点では、名前と説明のみが可能な追加値です (たとえば、「火の魔道士」と「マナ依存、注意してください!」)。

質問 1 : 2 つのクラスを持つことは理にかなっていますか、それともそれらをマージする必要がありますか? 前者の場合、この「付加価値（名前と説明）付き」のクラスはどこに置けばいいのでしょうか？アプリケーション層で？

質問 2 : ドメイン レイヤーは、私が取り組んでいる知識の領域を表し、アプリケーション レイヤーは、ドメインには存在しないが付加価値として提供したいすべてのものを表します。

(したがって、ソフトウェアが単にドメインを表す場合、アプリケーション層は薄く、ソフトウェアがドメイン以外の機能を多数提供する場合、アプリケーション層は厚くなりますか?)

追加情報 1:私のプロジェクトは、キャラクター シミュレーターの作成に関するものです。したがって、キャラクターをシミュレートするには、キャラクターとそのすべての依存関係を表現する必要があります。私のドメイン層の責任は、ゲームを表現することです。これには、いくつかのプロパティ (Life、Mana、Attack、Defence、Class) を持つ Character などのクラスと、いくつかの列挙型 (使用可能なすべてのクラスをリストする CharacterClass など) が含まれています。

ここで、自分のプロジェクトで、ゲームのキャラクターを表すプロジェクトを作成する機能をユーザーに提供したいと考えています。プロジェクトでは、ユーザーは、現在のプロジェクトの名前、メイン (およびセカンダリ) 機器セット、メイン (およびセカンダリ) スキルツリーなどの追加情報を保存することもできます。装備セットやスキルツリーの注釈も利用できるので、ユーザーは簡単に組み込みのメモ/ポストイットを持つことができます。セカンダリ装備セットとスキル ツリー、注釈はゲーム内に存在しない概念です (したがって、私のドメインには存在しません)。

質問1の「付加価値のあるクラス」とは、複数の情報（キャラクター装備、スキルツリー、アノテーションなど）の集合体であるキャラクタープロジェクトです。ユーザーが必要に応じて、物理サポートに保存し、後で開いて編集することができます。

質問 1 の再定式化: Character クラスと CharacterProject クラスがあります。CharacterProject クラスは、複数の情報の合成です。しかし、それは私のアプリケーションに固有のものです。アプリケーション層、ドメイン層、または他の場所に配置することは理にかなっていますか?

たとえば、2 つのサービスを必要とするアプリケーションがあるとします。Application、Service1、Service2

このオニオン アーキテクチャに従って、余分なレベルの間接化を構築し、サービスの 1 つをアプリケーション サービスに昇格させ、もう 1 つをドメイン サービスに降格させる必要があります。

または、 と の両方に直接接続する必要がありApplicationますか?Service1Service2

別のレベルの間接化を使用すると、Applicationレイヤーへの依存、特に外部サービスへの依存を減らすことができます。「Paypal」、「Facebook」、「Cyber​​Source」を使用して、プログラミング パラダイムにより適したアプリケーション サービス アダプターを作成します。結局、すべての開発者がこれらの多種多様な API に慣れ親しんでいることは、生産性にとって非常に有害です。ファサード/アダプタは、アプリケーションをインフラストラクチャの変更から保護しながら、開発を容易にします。例えば。同社は Cyber​​Source で失敗し、代わりに Paypal を使用することにしました。幸いなことに、アプリケーションはシールドされており、アダプターを変更するだけで済み、他には何も必要ありませんでした。

とはいえ、アダプターは間違いなく柔軟性を失います。アプリケーションが複雑になるにつれて、アダプターもリークしやすくなります。次に、潜在的に 3 つの問題があります: 漏れやすい抽象化、怠惰なレイヤー (穴が多すぎるために十分に機能していないレイヤー)、および一般的な閉鎖原則の違反です。UI を変更する必要があるときはいつでも、アプリケーションだけでなく、アダプタも。

そしてService2、同じ会社内ですでに内部サービスになっている場合はどうなりますか? サブシステムごとにアダプターを作成する必要がありますか? あなたのチームが小さい場合はどうなりますか？多様なテクノロジー セットを備えたチームが数十ある場合はどうなるでしょうか。別の間接レイヤーを追加することと、単にサービスを直接呼び出すことの妥当性についてのガイダンスはありますか?

私は ServiceStack と Onion Architecture を学んでいますが、あまりにも基本的な質問があり、何かが足りないと感じています。

Api、Core、Infrastructure の 3 つのプロジェクトがあります。

API プロジェクトに ServiceStack があります。コア プロジェクトにエンティティ オブジェクトがあり、インフラストラクチャ プロジェクトにデータ アクセス クラスがあります。Orm Lite コードがエンティティ オブジェクトの処理方法 (テーブルの作成など) を認識できるように、エンティティ オブジェクトを属性で装飾する必要があります。[AutoIncrement] や [Index] などの属性です。

属性にアクセスするには、コアで ServiceStack を参照する必要があります。この時点まで、コアは何にも依存していませんでした。これは、オニオン アーキテクチャの考え方を壊しています。

私は何が欠けていますか？エンティティがコアにあるときに、インフラストラクチャ プロジェクトの OrmLite がエンティティのデータ アクセスを処理できるようにするにはどうすればよいですか?

依存関係の反転を使用して、オニオン アーキテクチャとレイヤード アーキテクチャの違いを説明してくれる人はいますか? 彼らは私にはまったく同じように見えます。どんな入力でも大歓迎です:)