この質問には、実際にはより大きなアーキテクチャへの影響があり、これに関する意見や提案を歓迎します。

OOP に関して言えば、私は Martin Fowler 流の考え方です。UI でドメイン エンティティを直接レンダリングできるはずです。Car エンティティがあれば、それを Web ページにレンダリングできるはずです。ドメイン モデルは分野横断的な関心事であり、レイヤーではありません。ドメインモデルをレイヤーとして扱うと、ドメインモデルが貧血になります。私は OOP アーキテクチャの DTO を信じていません。

私にとってのビュー モデルは、ビューに必要なドメイン エンティティを構成する方法です。DTO ではありません。オートマッパーを使用するのは一般的なことのように思えますが、DTO のようなビュー モデルを使用する理由がわかりません。

そのため、メタデータ アプローチを使用して、ドメイン モデルにデータ アノテーションを配置し、エンティティのレンダリング方法と検証方法に関する UI 実装のヒントを提供します。私はよりリッチなドメインモデルが好きです。

MVC3 では、UI レイヤーに存在するリソース ファイルを使用して (具体的には Display data アノテーションを使用して) どのようにこれを達成できますか? これにはネイティブな実装がありますか、それとも自分で工夫する必要がありますか? それとも、私のアプローチのどこかで間違っていますか？

トランザクション スクリプト (サービス層) アーキテクチャの代わりにドメイン モデル アーキテクチャを使用する ASP.NET MVC のオープン ソース プロジェクトはありますか? 小さな例ではなく、プロジェクトの詳細を探しています。

大きな木が人がいる複雑なシステムがあるとします。単純な考えは従業員/マネージャーの関係であり、多くの従業員が1人のマネージャーに報告します。現在、マネージャーに加えて、マネージャーに代わって行動することができるサポートスタッフがマネージャーの従業員を操作することができます。

CQRSシステムでは、アクションの呼び出し元がサポートスタッフである、「従業員の編集」という架空のアクションのメッセージをどのようにモデル化しますか。このアクションは、マネージャーのセキュリティ関係に従ってスタッフが自分の領域の従業員に作用している場合にのみ成功します。

これのセキュリティを検証するには、データベースにクエリを実行して、変更される人物が実際にそのマネージャーの従業員チェーン内にいることを検証する必要があります。

このクエリはどこで発生しますか？「従業員の編集」メッセージを発信する前に？

メッセージを発信する前にデータが事前に検証されている場合、結果整合性のあるシステムでは、「従業員の編集」メッセージが処理される前に、「従業員の編集」アクションを完了するためのユーザーの権限を削除する別のアクションが発生したと想定します。 。コマンドハンドラーがそのメッセージのセキュリティ上の懸念を検証しない場合、ユーザーがメッセージを実行する権限を失っても、メッセージは引き続き成功します。

これは、UI検証やサーバー側検証と同様に、両面検証が最善の行動であることを意味しているように思われます。ただし、その検証を完了する方法は、CQRSの主要な信条に違反しているように見えます。

CQRSを使用するときに、これらおよび他の同様の横断的関心事に対処する必要がある場合、どのアプローチが最適ですか？

私は ASP.NET を初めて使用するので、私の質問は愚かで、長年の Java/JSF の使用に影響されている可能性があります。

ASP.NET と MVC3 および Entity Framework 4.1 を使用して Web アプリケーションを実装したいと考えています。これはビジネス アプリケーションであるため、データ操作を防止し、並行性を確保することにより、セキュリティを確保する必要があります。

そこで、Entity Framework がサポートする楽観的ロックを使用することを計画しました。しかし、MVC パラダイムとそれが提供するオプションの使用に関しては、上記のセキュリティ面をどのように実現すればよいかわかりません。

例

属性を持つエンティティタイプ「顧客」のドメインモデルがあります

• ID (データベース PK)
• 名前
• 誕生日
• バージョン (楽観的ロックに使用)

ビューがそのデータを編集できるように準備するために、次の属性を持つビュー モデル「customerView」を追加で使用します。

• 名前

コントローラーでは、データベースから特定のレコードを読み込み、値をビュー モデルに転送して、厳密に型指定されたビューに配置します。これはうまく機能します。値は Web フォームに表示され、変更をポストバックできます。ビュー モデルには ID とバージョンが含まれていない (その結果、ポストバックの一部ではない) ため、要求応答ライフサイクル中に失われたため、値をドメイン モデルにマップすることができません。

確かに、ID とバージョンを非表示の入力フィールドとして追加できますが、これはデータ操作が可能になるので避けたいものです。データを送信する前に誰かが ID またはバージョンを変更する可能性があります。サーバーに送信されたデータと Web フォームに配信されたデータ (特に ID とバージョン) を比較できないため、望ましくない動作が発生する可能性があります。

不要なフィールドを前後に送信しないようにするために、セッションで編集ビューを表示する前に取得したデータレコード/ドメインモデル (または少なくともレコードの ID) を保存する方法があると思いますが、そうではないことはわかっていますアプリケーションのパフォーマンスに影響を与える可能性があります。SQL Server などのデフォルトのセッション状態とは別のセッション状態を使用するのはどうですか? これにより、ビュー モデルから値を転送するためにデータベースからレコードをもう一度読み込む必要がないため、少なくとも 1 つのデータベース操作を節約できます。セッションからドメイン モデル レコードを取得でき、データ操作をチェックすることさえできます。

この例が、私が直面している問題を示していることを願っています。

これらの問題に対処するためのさらに良い方法があるかもしれません。多分私は完全に混乱しています;）

私はレンタカーのウェブサイトのドメインでdddのいくつかの側面を研究しようとしています。

ユーザー/顧客は、出発地と目的地の駅と期間から車を選択します。

価格の計算は、支払い方法、時間、車の分類など、さまざまなものによって異なります。データは、アプリケーションの他の部分とはデータアクセス戦略が異なるサブシステムから取得されます。

ドメインには、ステーションサービス、コールセンターなど、いくつかのアクターがいます...

制限されたコンテキストのアイデアは

• 会社（従業員、車、駅）
• 予約（予約、予約リクエストプロセスのモデル）
• 価格（価格モデル）
• 請求（レンタル請求、ポジション、顧客）

境界付きコンテキストを定義した後、それぞれの集約されたルートが正しいかどうかわかりません。私の考えは

• 会社：3つすべて
• 予約：予約（請求書、車、顧客へのアクセス）
• 価格：料金表
• 請求：顧客（予約へのアクセス、請求）

必要に応じて、クラス図を追加して、さまざまな境界コンテキストを表示できます。さらに情報が必要な場合は、クラス図またはこれを他のセクションに移行する必要があります。お気軽に質問/実行してください。

序章

3 つのドメイン オブジェクトがあるとします。

提案は、1 つ以上のフェーズを持つことができます。フェーズには、1 つ以上のタスクを含めることができます。

最後のフェーズの最後のタスクを完了した場合、提案は「クローズ」に設定する必要があります。

コードでは、フェーズの最後のタスクを完了するためにこのようなものを作成しました

質問

提案を「クローズ」に設定するコードはどこに配置すればよいですか?

オプション

いくつかのオプションがあると思います：

1) ドメイン エンティティ内: Task.SetComplete

2a) ビジネス層で

2b) ビジネス層では、おそらくもう少し良い方法です:

3) すべてを命題に通す:

オプションについて

オプション 1は回線上で問題があります

命題はロードする必要がなく、ロードされていない場合は例外が発生するためです。

オプション 2aには問題があります。これは、phase.LastTask.SetComplete() が実行された後、命題が正しい状態にないためです。そして、フェーズにアクセスできるコード内のどこでも、"phase.LastTask.SetComplete()" は命題に関連する操作を実行せずに実行できます。

オプション 2bには 2a と同じ問題があります。

オプション 3では、命題クラスに過度の責任が与えられます。

何か提案はありますか？

コードファーストはデプロイメントに最適ですが、開発中は、本番環境に移行した後、コードファーストの方法でドメインモデルに加えられた変更をプッシュスルーする方法がわかりません。

本番環境で蓄積されたデータをどうすればよいですか？

データをバージョンAスキーマからバージョンBスキーマに手動で移行することになっていますか？変更が壊れるのを防ぐために、スキーマをコード化する必要がありますか？最初の展開後にコードファーストに別れを告げ、データベースファーストに切り替えますか？

私は何が欠けていますか？

私は ASP.Net MVC4 を使用してアプリケーションを作成しており、データの大部分は MongoDB に格納されています。これは、私がアプリケーションの「肉」と見なすものの大部分、つまりアプリケーションを際立たせるために作成された機能でうまく機能しました。

ただし、静的コンテンツと管理機能 (アカウントの設定、請求、ヘルプなど) を追加する必要があります。私は、Orchard CMS を使用してこのすべての機能を処理し、これまで行ってきたことを Orchard モジュールに移行することを強く望んでいます。

問題は次のとおりです。Orchard のコンテンツ タイプを使用してモデル化する必要のあるデータの量は? 少なくとも一部のデータは引き続き Mongo に保存する予定です。そのため、何がどこにあるのかを分ける境界線をどこに置くべきかわかりません。

以前に Orchard で Web アプリケーションを実装したことがありますか? ドメインデータはどこに行きましたか? コンテンツ タイプを使用した場合、何か教訓はありましたか?

ドメイン モデルでは、ビジネスのデータを模倣するオブジェクト (つまり、db エンティティ) と、ビジネスが使用するルールをキャプチャするオブジェクト (つまり、データ検証、セッション状態) を持つことが最善です。

抽象化、永続層のアーキテクチャ (データマッパー、アクティブレコード) のためのリソースがたくさんあります。しかし、ビジネス ルール層はどうでしょうか。アーキテクチャ パターンやビジネス ルールの構築方法はありますか? 私はそれほど経験がなく、大きなアプリで一人で働いています。ヒント、新しい情報を検索します。

これは、ビジネスルール（検証ルール）/永続層アーキテクチャ、構造について少し話している記事です：http://forum.springsource.org/showthread.php?18699-Domain-Models-and-Validation-%E2% 80%93-An-Architectural-Discussion

いくつかの db 固有のルールをエンティティ オブジェクトに入れることができます (つまり、string、str length -varchar(100) のチェックなど) が、ユーザー入力を管理する他のルールが必要です (ユーザー データの検証は非常に反復的です - いくつかあるかもしれません)。パターンまたはこれらの種類のルールのいくつかの一般的なアーキテクチャ) 。また、セッションを管理するその他の基本的なルールがあります。

では、ビジネス ルール層に共通の構造/アーキテクチャ/パターンはありますか?

PS: MVC 構造の操作。私は太ったモデルや痩せたコントローラーのアイデアの熟達者です。MVC の M のスケーラブルなアーキテクチャ/構造はありますか?

私はphp/mysql CMSプロジェクトを終了しました。私のクラスの1つでは、grailsが主要なテーマであるため、それをもう少し試して、CMSをgrailsアプリに適合させてみませんか。

私は現在、、、、およびの4つのクラスで構成されるドメインをモデル化していUserます。はアプリのメインドメインであり、多くのドメインがあります。各オブジェクトには、多数の単一のがあります。LabsFilesSupportUserLabsLabsFilesSupport

の目標は、特定のラボに接続されているSupportすべてのものを参照することです。Users各ラボには、リード、0人から多数のスタッフ、およびファカルティアドバイザーがいます。私の問題は、これをGrailsでどのようにモデル化するかです。私は現在、クラスでUser leadとUser facultyを宣言していますが、0から多くのサポートスタッフを管理する方法がわかりません。

私がを行う場合static hasMany [user:User]、これは、にUser接続されているものSupportが区別される役割なしで追加されることを意味します。

助言がありますか？