3

私の会社は DDD を採用しようとしています。DDD のガイダンスは、ドメイン アセンブリにすべてのサービス インターフェイスを定義することを要求し、実装者がドメイン アセンブリを参照してサービス インターフェイスを実装できるようにすることのようです。次に、DI を使用してドメインが実装を取得します。ただし、横断的な懸念事項については、ドメイン アセンブリに、そのアセンブリのコア ビジネス ドメインではないロギングなどのインターフェイスを再定義するよう要求するのは無責任に思えます。私は、Quartz.NET のような多くの商用コンポーネントが、Apache Commons のような標準的で広く受け入れられている一連のインターフェースを使用して、横断的な問題をフレームワークに適した方法で解決していることに注目しました。これは DDD の方法と一致していますか、それとも AOP のようなフープを本当にジャンプしていますか?

参考のため：

http://www.infoq.com/articles/ddd-in-practiceから

「これらは再利用可能な非ドメイン関連の問題であり、通常、ドメイン層を含むコード全体に分散して複製される傾向があります。このロジックをドメイン オブジェクトに埋め込むと、ドメイン層と非ドメイン関連のコードが絡み合い、混乱することになります。」

http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/から

「あなたの分野横断的な関心事は、他の誰かのコア ドメインです」

4

2 に答える 2

6

DDD のガイダンスでは、ドメイン アセンブリを要求するようです。

DDD は何も必要としません。ドメイン層は、ドメインの概念とユース ケースをグループ化します。ドメイン レベルで定義された抽象化は、ドメイン自体に必要です。そして、ドメインのユースケースで必要とされることを意味します。ロギングは、インフラストラクチャ (技術) の側面です。通常、このような抽象化は共通の共有レイヤー/コンポーネントの一部であり、アプリのすべての部分で使用できます。

ドメインはこのようなことには関心がなく、DDD はレシピや「ハウツー」と見なされるべきではありません。これは、アプリの設計がビジネス コンセプトとユース ケースを中心に展開し、他のすべての技術的側面が実装の詳細であるという考え方です。

「あなたの分野横断的な関心事は、他の誰かのコア ドメインです」

これは、単にサポート システムである機能を意味し、他のコンポーネントの目的 (ドメイン) です。

DDD についてもっとよく読んで、考え方を理解し、アプリのユースケース アプローチを採用することをお勧めします。あなたのアプリは、多くの特殊なミニアプリのグループと考えてください。それぞれに独自の懸念がありますが、他のアプリと通信する必要があります。コンポーネントごとに構築した場合は、DDD を理解していることになります。また、アジャイルも実践していることになります。

于 2015-07-30T19:18:29.790 に答える