問題タブ [cross-cutting-concerns]

私の会社は 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/から

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

RESTful API を実装し、次のようなファイル構造をセットアップします。

管理者/sudo ルートはapi/admin/entity_name.tsまたはに入ることができapi/entity/admin.tsます。

前者は、すべての管理コントロールが 1 か所にあり、監査、標準化、すべての管理者アクセスの無効化などが容易になるため便利です。後者は、「通常のユーザー」の実装に非常に近いため便利です。

どのオプションが最適ですか?

私はマントラを使って流星でアプリケーションを開発しています。usersモジュールのroutes.jsxです。requireLoginandredirectUsersを他のモジュールのアクションとルートで使用できるようにしたいです。または、一般的に、マントラのアーキテクチャに違反することなく、横断的な懸念にどのように対処すればよいでしょうか?

AOP 内で使用される懸念の分離を理解しようとしています。したがって、基本的な HelloWorld の例を使用して、AOP でのコードの分散とコードのもつれの意味を誰かが説明してくれれば幸いです。特定の懸念がシステムコアの懸念ではなく、側面である場合、後でどのように知ることができますか? どうもありがとう。

MVC レイヤード アプリケーションがあり、クロス カッティング レイヤーについていくつか質問があります。これまでのところ、この層にはロギング、DI、エラー処理、およびキャッシュがあります。

プロジェクトを作成し、これらすべての機能をフォルダーごとに分けました。これでよろしいですか？それとも、機能ごとにプロジェクトを作成する必要がありますか?

このプロジェクトで Autofac (DI フォルダー) をセットアップしたため、他のプロジェクト (モデル、リポジトリ、およびサービス) への参照を追加する必要がありました。これらの参照を Cross Cutting プロジェクトに追加してもよろしいですか?

共通の機能をグループ化するために個別のプロジェクトを作成する必要がありますか? たとえば、列挙型、定数、および GetMd5Hash などのメソッドです。または、そのためにクロスカッティングプロジェクトを使用する必要がありますか?

Automapper を横断的な関心事と見なす必要がありますか? これまでのところ、Entity から ViewModel に、ViewModel から Entity に変換するために、プレゼンテーション レイヤーに設定しました。そのため、回避したい Model への参照を追加する必要がありました。