0

DDDを念頭に置いて設計しようとするN層アプリケーションがあります。アプリは REST サービスとして公開されます。状態パターンを利用するドメイン エンティティがあります。状態のインターフェースはこのようなものです

interface IDomainObjectState
{
    void SetPassed();
    void SetFailed();
    void SetIncomplete();
    void Pause();
    void Block();
}

このエンティティには Status フィールドもあります。「Set」で始まる状態メソッドは、オブジェクトの状態が許せば、このフィールドを変更することになっています。

これにより、ドメイン内のコードをかなりクリーンにすることができますが、サービス レイヤーでは問題があります。別の REST リソースを使用してエンティティのステータスを変更します (たとえば、これPUT /resultを実行します)。私を泣かせる問題はswitch、これら 3 つの方法のいずれかを選択するために DTO に導入された新しいステータスになっていることです (そして、それを行う唯一の方法はアプリケーション層にあると思います)。

3 つの「Set*」メソッドを 1 つにマージするのは良い考えですか? そうでない場合は、別のリファクタリングを提案してください。

4

1 に答える 1

1

3 つの「Set*」メソッドを 1 つにマージするのは良い考えですか?

HTTP インターフェースとの統合を簡素化することが唯一の動機である場合、それは得策ではありません。IMO、switch ステートメントは、アダプター/ACL コードの一部であり、一般的に簡単で、簡単にテストでき、優れた設計を必要としないため、ひどいものではありません。理想的には、HTTP アダプターは、目前の動作をカプセル化するアプリケーション サービスを呼び出します。必要に応じて、特定の HTTP リソース/動詞の組み合わせとアプリケーション サービス メソッドとの間のマッピングを作成できますが、これは全体としてあまり価値がありません。

于 2013-05-16T17:20:17.890 に答える