0

貧血ドメインモデル（ADM）があるとしましょう：

public class Employee
{
    public Employee() 
    {
        _roles = new List<Role>();
    }

    private IList<Role> _roles;

    public Guid Id { get; set; }
    public string Name { get; set; }

    public IList<Roles> Roles { get { return _roles; } }
}

public class EmployeeManager
{
    public Employee GetByName(string name) 
    {
        Contract.Requires(name != null);

        return repositoryOfEmployeesInstance.GetByName(name);
    }

    public void AddEmployee(string name) 
    {
        Contract.Requires(name != null);

        // The unique identifier will be generated by the OR/M behind the scenes...
        repositoryOfEmployeesInstance.Add(new Employee { Name = "Matias" });
    }
}

後で、他の場所で、次のコードを使用します。

Employee some = new EmployeeManager().GetByName("Matias");
some.Roles.Add("Principal");

現在、ドメインモデルに加えて、実装DomainValidationAspectで永続化される直前に新しい従業員を検証するという側面があります。Repository

全体は、役割を追加する場合のように、追加または更新されたときにValidateEmployeeAspect検証できます。のドメインルールEmployeeをロードし、それらを検証する責任があります。Employeeドメインルールは、仕様パターンを使用して実装されます。

最後に、すべてがドメイントランザクションで発生します。

そうです、オブジェクト指向プログラミングの観点からは貧血のドメインモデルのようですが、アスペクト指向プログラミングについてはどうでしょうか。

だから問題は...

...ドメイン駆動設計は、次の理由だけで貧血になる可能性があります：

  • ...この場合、Employeeロールはコレクションインターフェイスを使用して追加されますか？
  • Employee...純粋なオブジェクト指向プログラミングの観点からの動作の欠如？

いくつかの言葉

私の意見では、アスペクト指向プログラミングには、ドメイン（または他のレイヤー）のメインフローに多くの詳細を隠すという欠点がありますが、オブジェクト指向とアスペクト指向の背後にある概念の鳥瞰図です。アプローチは、アネミックドメインモデルではなく、リッチドメインモデルにマッピングされます。

4

2 に答える 2

3

いくつかのポイントが思い浮かびます（順不同）：

  • ドメイン駆動設計では、集合体（ここでは従業員）が無効な状態になることは決して許されません。不変条件自体を強制するため、外部検証の必要はありません。

  • これは私にはCRUDに非常によく似ています。なぜ単純なCRUDにDDDを強制するのですか？

  • EmployeeManagerリポジトリメソッドをラップするだけで、複雑さのさらに別の層にすぎないことを除いて、何をしますか。

  • ArepositoryOfEmployeesInstanceは私には非常に人工的に聞こえます。EmployeeClassクラスやを呼び出さないのと同じようにEmployeeManagerClass、なぜオブジェクトに接尾辞を付けるのInstanceですか？

    また、なぜパターン名（ここではリポジトリ）を追加するのですか？先に進んで、それを呼び出しますemployees。それは本物のように聞こえます：

    employees.GetByName(name)

    またはさらに良い： employees.Called(name)

于 2013-01-11T10:58:14.287 に答える
1

私の意見では、アスペクト指向プログラミングには、ドメイン（または他のレイヤー）のメインフローに多くの詳細を隠すという欠点があるのは事実です。

IMO、これはDDDでこのようなAOPアプローチを使用する際の中心的な問題です。詳細が隠されています。現在、ロギングなどの厳密に技術的なドメインの場合、これが望ましいことがよくあります。AOPは、ある意味で技術ドメイン自体の特性であり、従来のOOP構成の拡張であるため、このようなドメインに適しています。一方、DDDは、非技術的なドメイン（ビジネスのユースケース）を対象としています。そのため、DDDの目標の1つは、ドメイン知識の抽出です。技術的な懸念から可能な限り解放します。OOPで達成するためのステップは、オブジェクト内でデータと動作をクラスター化することです。もう1つのステップは、動作の技術的な名前から、動作のよりビジネス固有の名前に移行することです。これにより、技術的なコンテキストだけでなく、動作に関連する周囲のビジネスコンテキストをキャプチャできます。

DDDに役立つのは、新しい抽象化のセットです。複雑さの不必要な層ではなく、新しいセマンティクスを作成するものです。ダイクストラが述べたように、抽象化は新しいセマンティックレベルを作成する必要があります。これは、技術的な懸念にとらわれないドメイン知識の表現を可能にするDSLの形で提供されます。次に、アプリケーションは、このDSL表現ドメインをインフラストラクチャ（永続性、UI、サービスなど）に接続します。表現力があり、簡単に「接続可能」であるようなDSLを作成することは大きな課題です。

あなたの質問に答えるために、はい、あなたのオブジェクトモデルは、アスペクトを通してより豊かな振る舞いで構成されているにもかかわらず、それ自体が貧血です。ただし、これはオブジェクトモデルにのみ対応し、オブジェクトモデルが貧血であるかどうかは、パズルの一部にすぎません。オブジェクトモデルは、戦略的なパターンではなく、戦術的なパターンです。

あなたの目標は正しい方向に向かっているようです-あなたはOOPだけで提供される機能を超えて抽象化のレベルを上げたいと思っています。AOPの欠点がDDDの場合の利点を上回っていると思います。

于 2013-01-11T17:35:02.443 に答える