10

現在、別のチームから引き継いだもののコードレビューを行っており、SRP の適用と貧血またはリッチドメインモデル (Martin Fowler によって定義されている) との関係について 1 つの疑問があります。リッチ ドメイン モデルの概念は、プロパティを設定/取得できるだけでなく、より複雑なビジネス ロジックを実行できるインテリジェントなオブジェクトを持つことです。SRPにどのように適合するのだろうか？

これらの小道具を公開し、そのプロパティでいくつかの簡単な計算を提供できるいくつかのプロパティを持つモデル クラスがあるとします。次の要件は、次のように、このオブジェクト データを自分の管理下にないストレージ オブジェクトに格納できるようにすることです。

class MyObject {
    // get set
    // parse sth
    
}

ストレージへの格納方法

   storage.store(key, object);

MyObject にこのような store メソッドがあれば SRP に違反しませんか?

public void store(Storage storage) {
    storage.store('keyOne', fieldOne);
    storage.store('keyTwo', fieldTwo);
}

このオブジェクトの視点から、その状態を保存できるのは良い考えです。別の方法として、ここにある種のサービスを導入して、次のようにすることもできます。

public StorageService {
    private Storage;
    // constructor here
    ....
    public void store(MyObject myobj);
}

この問題について読むことができるリンクを教えてもらえますか? SO here で1つのスレッドを見つけましたが、私の質問に完全には答えていません。

DDD ではどのように解決されますか? DDD のモデルは定義上リッチであり、責任が多すぎると見なすことができます。

4

3 に答える 3

7

リッチ ドメイン モデル ( RDM ) とは、ゲッター/セッターでモデルをデータのように扱うのではなく、モデルの動作を管理するロジックがモデル内に属していることを意味します。これは、永続性、セキュリティ、GUI でのモデルの表示方法などを含むすべてがモデル内にある必要があるという意味ではありません。

RDM と SRP は密接に連携しており、互いに競合することはありません。

SRP/RDM 違反:

Car {
   // possibly violates SRP
   storeInDatabase();  
   // smells like anemic domain model
   getEngineState();   
}

以下の SRP/RDM:

// usings aspects to remove cross-cutting concerns from the model and follow SRP
@DatabaseSerializable 
Car {
   // rich domain model encapsulates engine state and exposes behavior
   drive();            
}
于 2012-01-10T19:22:02.867 に答える
4

「DDD のモデルは定義上リッチであり、責任が多すぎると見なすことができます」は、DDD の単純な解釈です。常にそれはあなたのモデルがどれだけ優れているかにかかっています。DDD を使用して不適切なモデルを作成する可能性があります (たとえば、責任が多すぎるオブジェクトを作成したり、貧血モデルを作成したりするなど)。DDD と SRP は、リファクタリングや TDD などと同様に、従うべき 2 つの優れたプラクティスですが、自分の経験と判断 (または他の誰かの判断) でそれらの使用を補完する必要があります。すべてに長所と短所があります。実践を適用することについて独断的にならないでください。

于 2012-01-10T19:03:10.050 に答える
3

@ギャレット・ホール

「RDM と SRP は密接に関係しており、互いに競合することはありません」というあなたの発言には、私はやや同意しません。私の経験では、SRP が強調されすぎると、貧血ドメイン モデルにつながります。「いいえ、永続性をサポートすることはできません。サポートすることさえできません。21-CFR11 を行うことはできません。GUI が何であるかを知ることさえできません...」そして、クラスは何もせず、貧血ドメインモデルを持っているだけです。

そして、RDM が過度に強調されている場合 (これは私が陥りがちな方向/エラーです)、SRP は完全に脇道に落ち、最終的にクラスに何百ものメソッドがあり、明らかにやりすぎていることに気付きます。

バランス、つまり RDM と SRP の両方が発生している幸せな媒体を見つける必要があります。そして、そのバランスを見つけるのは難しく、技術的な知識やルールよりも、チーム内での直感や政治が必要になることがよくあります。

"汝自身を知れ"。あなたが私のようで、過度に複雑なクラスを好む傾向がある場合は、注意してください。そして、あなたにさえ複雑すぎるように見える他の誰かのクラスを見たとき、それは大きな危険信号です. 同様に、自分が SRP に非常に熱心であることがわかっていて、自分の基準から見ても貧弱に見えるクラスを見つけた場合、それは重大なコード臭です。

さて、ストレージに関するOPの質問にいくらか答えますが、ストレージがどれほど安定しており、標準的で、抽象的であるかに大きく依存していると思います。ストレージが標準的な XML、CSV、または RDB の抽象化である場合、オブジェクトが自身を格納する方法を知っていれば、まったく問題はありません。

于 2012-01-10T20:58:55.623 に答える