web-dev-qa-db-ja.com

クリーンアーキテクチャ-ユースケースの再利用にはどのように対処しますか？

アンクルボブのクリーンなアーキテクチャを、私が維持しているアプリケーションに適用しようとしていますが、使用例と複製/再利用に問題があります。ユースケースは自己完結型である必要があり、重複が予想されるというのは私の理解ですが、これは私が扱っていることには意味がないようです。最終的に他のユースケースを使用する必要がある複数のユースケースがあると思います。

個別に存在するが、次のように互いに依存し合う4つのユースケースの非常に簡略化された例を次に示します。

BulkSendUsersToUnit               
    SendUserToUnit   
        AddUserToMandatoryGroups  
            AddUserToGroup

それぞれに、常​​に適用される検証、リポジトリー呼び出し、および条件があります。基本的にこれをサービスで実行している場合、それらは単に、必要な場所から呼び出すメソッドです。

DIを使用して他のユースケースにユースケースを挿入できますか？

ここで何が欠けていますか？

architectureclean-codeuse-case
9
Dont trust me

ユースケースはメソッドではありません。
ユースケースはオブジェクトではありません。
ユースケースはレイヤーではありません。

ユースケース は、特定のケースでソフトウェアを使用しているユーザーに関するストーリーです。

したがって、さまざまなユースケースで同じコードを再利用できることは当然のことです。

しかし、多分あなたはビデオの1つを見ましたペイウォール Bobがユースケースのように理解できる場所は、アーキテクチャの一部です。

enter image description here

心配しないでください。それは彼のレイヤーの1つにあるボックスの名前にすぎません。 彼は他の名前を使用しています ：

enter image description here

これはボブおじさんが間違っていることを意味しますか？いいえ。インタラクター/ユースケース/アプリケーションビジネスルール/ Oh-pick-a-name-and-stick-with-itレイヤーでは、アプリケーションのニーズ（詳細）をすべて無視し、ユーザーのニーズに焦点を当てます特定のユースケースを通過します。ただし、コード内のこの場所はユースケースではありません。ユースケースは、ユーザーがボタンをクリックしてから結果が表示されるまでの全体のストーリーです。

それで、インタラクター（またはあなたが呼びたいもの）は他のインタラクターを使うべきでしょうか？さて、これは次のDRY=極端なものです。あなたはAddUserToGroupからのコードを他のどこかに置くことが許可されていませんか？

バロニー。 AddUserToMandatoryGroupsが別の意味を持ち、変更したい理由がAddUserToGroupとは異なる場合、AddUserToMandatoryGroupsに独自の追加ユーザーコードを指定してもかまいません。今のところ、AddUserToGroupのコードの文字コピー用の文字です。これらを互いに独立して変更できるようにする必要があると考える正当な理由がある場合、現時点でそれらが同一に見えるかどうかは問題ではありません。繰り返しアイデアにDRYを適用します。コードではありません。

Dependency Injectionに関しては、いつから何を切り離したい場合でも、それはうまく機能します。

Bulk shitlist = new Bulk(annoyingUsers, bannedForLifeUnit);

Register.OnIveHadAllICanTake( ()-> shitlist.send() );
15
candied_orange