DDDの実装：ユーザーと権限

私は、ドメイン駆動設計の原則を把握しようとする小さなアプリケーションに取り組んでいます。成功した場合、これは大規模プロジェクトのパイロットになる可能性があります。「Implementing Domain-Driven Design」（Vaughn Vernon著）を読み、同様のシンプルなディスカッションフォーラムを実装しようとしています。また、githubでIDDDサンプルをチェックアウトしました。私は自分のケースにアイデンティティとアクセスを採用するのに苦労しています。背景情報をいくつかご紹介します。

• 私は（願わくば）ユーザーとアクセス許可のロジックを分離する背後にある理由を理解しています。それはサポートドメインであり、異なる境界コンテキストです。
• コアドメインには、ユーザーはなく、作成者、モデレーターのみが存在します。これらは、サービスを使用してIDおよびアクセスコンテキストにアクセスし、受信したユーザーオブジェクトをモデレーターに変換することによって作成されます。

• ドメイン操作は、関連する役割をパラメーターとして呼び出します。例：

  ModeratePost( ..., moderator);

• ドメインオブジェクトのメソッドは、指定されたモデレーターインスタンスがnullでないかどうかを確認します（IDおよびアクセスコンテキストから要求されたユーザーがモデレーターロールを持っていない場合、モデレーターインスタンスはnullになります）。

• ある場合には、投稿を変更する前に追加のチェックを行います：

  if (forum.IsModeratedby(moderator))

私の質問は：

• 後者の場合、セキュリティの懸念がコアドメインに再び溶け込んでいないのですか？以前は、本は「誰が主題を投稿できるか、またはどのような条件で許可されていますか。フォーラムは著者が今それをしていることを知る必要があります」と述べていました。

• 本のロールベースの実装は非常に簡単です。モデレーターがコアドメインである場合、必要なときに現在のユーザーIDをモデレーターインスタンスまたはオーサーに変換しようとします。サービスは適切なインスタンスで応答するか、ユーザーに必要なロールがない場合はnullで応答します。ただし、これをより複雑なセキュリティモデルにどのように適合させることができるかわかりません。私がパイロットをしている現在のプロジェクトには、グループ、ACLなどのかなり複雑なモデルがあります。

「投稿はその所有者または編集者のみが編集する必要があります」のようにあまり複雑ではないルールでさえ、このアプローチは破綻しているように見えます。

IdentityOrAccessコンテキストにOwnerOrEditorインスタンスを要求することは適切ではないと感じ、コアドメインではますますセキュリティ関連のクラスになります。さらに、userIdだけでなく、保護されたリソースの識別子（投稿、フォーラムなどのID）をセキュリティコンテキストに渡す必要があります。 ）

コアドメインへのアクセス許可を引き出し、ドメインオブジェクトのメソッドまたはサービスでそれらをチェックすることで、最終的には、セキュリティに関する懸念をドメインに混在させることになります。

セキュリティとアクセス許可がコアドメイン自体でない限り、これらのアクセス許可関連のものはコアドメインの一部であってはならないことをどこかで読みました（そしてそれに同意する傾向があります）。上記のような単純なルールは、セキュリティをコアドメインの一部にすることを正当化しますか？

実際のアクセス制御ルールと、アクセス制御の境界を定めるドメイン不変条件を区別するのは難しい場合があります。

特に、特定のドメインロジックの過程で使用可能なデータのみに依存するルールは、ドメインから簡単に抽出できない場合があります。通常、アクセス制御はドメイン操作の実行前または実行後に呼び出されますが、実行中は呼び出されません。

Vaughn Vernonのassert (forum.IsModeratedBy(moderator))例はおそらくドメインの外にあったはずですが、常に実行可能であるとは限りません。

userIdだけでなく、保護されたリソースの識別子（投稿、フォーラムなどのID）をセキュリティコンテキストに渡す必要がありますが、セキュリティコンテキストはおそらくこれらのことを気にする必要はありません（正しいですか？）

セキュリティBCがあり、そのロジックを処理する場合、フォーラムの詳細を知る必要はありませんが、

• 「moderated by」などの概念の知識があれば、それに応じてアクセス権を許可または拒否できます。
• コアドメインイベントをサブスクライブし、セキュリティBCが保存および使用するための単純な（リソース、authorizedUsers）キー値ペアに変換するアダプターロジックを使用できます。

認証と承認は、DDDの悪い例です。

会社がセキュリティ製品を作成しない限り、これらはいずれもドメインの一部ではありません。

ビジネスまたはドメインの要件は、「ロールベースの認証が必要」です。

次に、ドメイン関数を呼び出す前にロールを確認します。

「自分の投稿は編集できますが、他の投稿は編集できません」などの複雑な要件がある場合は、ドメインで編集機能EditOwnPost()をEditOthersPost()ので、あなたが役割へのマッピングの単純な機能を持っていること

また、このようなとして、ドメインオブジェクトに機能を分離することができます Poster.EditPost()し、Moderator.EditPost()あなたの選択はあなたの方法は、ドメインサービスまたはドメインオブジェクトであるかどうかにもよるが、これは、より多くのOOPのアプローチです。

ただし、ロールマッピングはドメイン外で発生するコードを分離することを選択します。たとえば、webapiコントローラーがある場合：

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

ご覧のとおり、ロールマッピングはホスティングレイヤーで行われますが、自分自身または他のユーザーの編集を構成するものの複雑なロジック投稿のドメインの一部です。

ドメインはアクションの違いを認識しますが、セキュリティの要件は単に「機能はロールによって制限される」ことですです。

これはおそらくドメインオブジェクトの分離によってより明確になりますが、本質的には、サービスメソッドを呼び出すメソッドの代わりにオブジェクトを構築するメソッドをチェックしています。ドメインの一部としてそれを表明したい場合の要件は、「モデレーターのみがモデレーターオブジェクトを構築できる」ことになります。