6

DDDの原則を使用して、RBACベースのユーザー保守システムをモデル化しようとしています。次のエンティティを特定しました。

Authorization is an Aggregate Root with the following:
    User   (an entity object)
    List<Authority>    (list of value objects)

Authority contains the following value objects:
    AuthorityType (base class of classes Role and Permission)
    effectiveDate

Role contains a List<Permission>
Permission has code and description attributes

典型的なシナリオでは、ユーザーメンテナンスのすべてがそれを中心に展開するため、承認は間違いなく集約ルートです（たとえば、ユーザーに役割または権限のいずれかである1つ以上の権限を付与できます）

私の質問は：役割と許可はどうですか？それらはまた、それら自身の別々のコンテキストでルートを集約しますか？（つまり、承認、役割、許可の3つのコンテキストがあります）。すべてを1つのコンテキストで組み合わせることができますが、役割は承認の「オブジェクトグラフ」の一部として読み込まれるため、重すぎるのではないでしょうか。

4

1 に答える 1

36

第一に、私はあなたが制限された文脈の概念を誤解していると感じずにはいられません。あなたがBCとして説明したものは、私がエンティティとして説明します。私の考えでは、制限されたコンテキストは、ユビキタス言語で定義されたエンティティに、特定のコンテキストに対して異なる目的を与えるのに役立ちます。

たとえば、病院のドメインでは、外来患者部門で治療を受けている患者は、紹介のリストとBookAppointment（）などのメソッドを持っている場合があります。ただし、入院患者として扱われている患者には、 WardプロパティとTransferToTheatre（）などのメソッドがあります。これを考えると、患者が存在する2つの制限されたコンテキストがあります：外来患者と入院患者。保険分野では、営業チームがポリシーをまとめましたこれにはある程度のリスクが伴い、したがってコストがかかります。しかし、それがクレーム部門に届いた場合、その情報は彼らにとって無意味です。ポリシーが請求に対して有効であるかどうかを確認するだけで済みます。したがって、ここには2つのコンテキストがあります。販売と請求

次に、DDDの実装を実験する際に、例としてRBACを使用していますか？私が尋ねる理由は、DDDが複雑なビジネス上の問題、つまり計算が必要な場合（ポリシーのリスクなど）を解決するのに役立つように設計されているためです。私の考えでは、RBACはかなり単純なインフラストラクチャサービスであり、実際のドメインロジックとは関係がないため、厳密なDDD実装を保証するものではありません。DDDは投資に費用がかかるため、それだけのために採用するべきではありません。これが、制限されたコンテキストが重要である理由です。正当な場合にのみ、DDDを使用してコンテキストをモデル化します。

とにかく、この答えが「アカデミック」に聞こえるリスクを冒して、これをDDDとしてモデル化することを想定して、質問に答えようとします。

私にとって、これはすべて1つのコンテキスト（「セキュリティ」などと呼ばれる）に適合します

一般的な経験則として、独立したトランザクションを必要とするすべてのものを集約します。

  1. システムが権限をAuthorizationオブジェクトに追加することを許可していると仮定して、Authorizationを集約にします。（承認を破棄し、ユーザーを権限のリストを含む集約ルートにすることについての議論があるかもしれませんが）
  2. 権限は、承認集計以外では意味を持たず、追加時にのみ作成されるため、これらはエンティティとして残ります。
  3. システムがパーミッションをロールに追加できることを前提とすると、ロールは集約ルートになります。
  4. アクセス許可を作成/削除できないことを前提としています。つまり、アクセス許可はシステム自体によって定義されるため、これらは単純な値オブジェクトです。

骨材のデザインについては、これらの記事を十分にお勧めすることはできません。

于 2012-07-05T12:24:34.963 に答える