2

私はドメイン駆動設計を始めたばかりで、次のような構造のドメインのプロジェクトがあります。

ドメイン

  • /エンティティ
  • /境界
  • /ユーザーストーリー

私が DDD を理解しているように、外の世界がドメインと通信する境界は別として、ドメイン内のすべてが見えないようにする必要があります。ドメイン内のエンティティ クラスについて私が見たすべての例には、パブリック アクセス修飾子があります。たとえば、ここでは Message という名前のエンティティがあります。

public class Message
{        
        private string _text;

        public string Text
        {
            get { return _text; }
            set { _text = value; }
        }

        public Message()
        {

        }

        public bool IsValid()
        {
           // Do some validation on text
        }
}

エンティティ クラスとそのメンバーが内部としてマークされ、ドメイン プロジェクト内でのみアクセスできるようにすると、より正確ではないでしょうか?

例えば：

internal class Message
{        
        private string _text;

        internal string Text
        {
            get { return _text; }
            set { _text = value; }
        }

        internal Message()
        {

        }

        internal bool IsValid()
        {
           // Do some validation on text
        }
 }
4

1 に答える 1

2

ここには混乱があると思います: Bounded Context は、モデルが有効であるコンテキストを定義する概念であり、実際には Boundary という名前のクラスはありません。これらは破損防止のためのオブジェクトである可能性がありますが、実際には集約ルートは境界コンテキスト内のそのエントリ ポイントまたは何らかのエントリ ポイントを処理する必要があります。

私はこのようなドメインを構築しません。これは人為的なものです。実際のプロセスで意味のあるものに従ってドメインを構築する必要があります。あなたは DDD を使用してコードで現実世界のプロセスをモデル化していますが、ソフトウェア開発以外でエンティティや値オブジェクトについて話している人は聞いたことがありません。彼らは注文、製品、価格などについて話します

ところで、ドメインが実際に各メッセージを一意に識別する必要がない限り、そのメッセージはほぼ確実に値オブジェクトです。ここで、メッセージはドメインの概念です。コマンドやイベントを意味していないことを願っています。そして、バリデーションをコンストラクターまたは新しい値が与えられるメソッドに入れる必要があります。

公平を期すために、このコードは単純化する方法です。おそらく、間違った例を選択したのでしょう。クラスが内部またはパブリックであることについて、それらはいずれかである可能性がありますが、それはルールではなく、多くのことに依存します。極端な例では、ほぼすべてのオブジェクトが内部にあるものの、アプリケーションに共通のパブリック インターフェイスを実装するというアプローチがあります。これは非常に非効率的です。

経験則: クラスがドメイン アセンブリの外部で使用される場合はパブリックにします。ドメインによって内部的に使用されるものである場合、および/またはパブリック インターフェイスを実装する場合は、内部にします。

于 2012-11-18T12:59:47.287 に答える