2016-01-29 6 views
6

Robert MartinのClean Architectureをプロジェクトに導入することを検討しています。私は、自明ではないユースケースを処理する方法を見つけようとしています。クリーンアーキテクチャー - Robert Martin - ユースケース粒度

複雑な/構成されたユースケース、特に、ある種のバッチ処理を実行するシステムのように、アクターがユーザーではなくシステムである場合に、アーキテクチャをスケールすることは困難です。説明の目的のために

、のすべてのリストを取得」、「すべてのアカウントのリストを取得します」、また

class UpdateAllAccountBalancesInteraction { 
    function Execute() { 
     Get a list of all accounts 
     For each account 
      Get a list of all new transactions for account 
      For each transaction 
       Perform some specific calculation on the transaction 
      Update account balance 
    } 
} 

のような擬似コードで実装「システムは、すべての口座残高を更新」のようなユースケースを想定してみましょう「アカウントの新しいトランザクション」、「トランザクションの特定の計算を実行する」、「アカウントの残高を更新する」はすべて独自の有効なユースケースであり、それぞれ独自の相互作用クラスで既に実装されています。

いくつかの質問が生じ:

  • が将来の事業から が(でも有効な ユースケース「システムは、すべての口座残高を更新」またはそれは小さなユースケースに分けるべきであるユースケースです意味があるようですが、 正当なビジネスシナリオです)?
  • UpdateAllAccountBalancesInteraction は正当な相互作用ですか?
  • 他のやりとりをオーケストレーションすることができますか?
  • 他の インタラクションを実際に他の場所に編成するコードですか?
  • それが相互作用として UpdateAllAccountBalancesInteractionを持っているが、他の相互作用の オーケストレーターとして、他の相互作用ではなく、行為によって共有それ 通話機能を持っているだけでOKですか?

答えて

1

明らかに、低レベルのやりとりで共通の機能の一部(または多く)を共有する新しい高レベルのやりとりがあります。これで結構です。

ビジネスにUpdateAllAccountBalancesというユースケースが必要な場合は、有効なユースケースであり、ビジネスロジックを反映するように名前を付けることをお勧めします。

これはo.kです。これがビジネスロジックを正確に反映している場合は、他のインタラクションを呼び出すための1つのインタラクションがあります。 UpdateAccountBalanceの要件が変更された場合は、まったく同じ方法でUpdateAllAccountBalancesにも影響するのでしょうか?答えが「はい」の場合は、UpdateAllAccountBalancesUpdateAccountBalanceとすることをお勧めします。そうしないと、一貫性を保つために2か所で変更する必要があるためです。答えが「いいえ」の場合、2つの相互作用を切り離したいと考えています。これは、共有関数を呼び出すことによって実行できます。

+0

私は私の心を作ると私のプロジェクトを進めていたので、私は例がプレゼンテーション/ [記事](https://blog.8thlight.com/uncle-bob/2012/08/で提供することを結論付けました13/the-clean-architecture.html)は些細なことであり、依存関係の分離はレイヤーを指していると私は同意するのは簡単だと思います。そのことを念頭に置いて、あるインタラクションの 'Execute()'メソッドは別のインタラクションの 'Execute()'メソッドを呼び出すべきではないが、同じレイヤーでコードを確実に共有できると結論づけました。 – PlusInfinite

0

私の提案は、問題に異なってアプローチすることです。手続き型アプローチを使用するのではなく、ドメインモデルで問題自体を表現します。ユースケースの問題のいくつかを見てください。その1つは、その粒度が一般的に不確定であるということです。

ドメインモデルでは、具体的なというものを表す標準的な方法は、(すなわち、「アカウント」)に2つのオブジェクトがあります。1つは特定のアカウントを表し、関連するオブジェクトはすべてのアカウントに共通のものを表します。

AccountCatalog (1) ---- (*) SpecificAccount 

たとえば、SpecificAccountにはサービス(メソッド)「UpdateBalance」があります。 AccountCatalogには、サービス(メソッド) "UpdateAllBalances"があります。このメソッドは、そのコレクション内のすべてのSpecificAccountにUpdateBalanceというメッセージを送信します。

これでUpdateAllBalancesメッセージを送信できます。別のオブジェクト、人間のやりとり、または別のシステム。

アカウントが更新するように通知するのではなく、自分の残高を「知っている」(つまり維持している)ことが一般的であることに注意してください。

+0

[Clean Architecture](https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html)のアプローチは、説明したのと同様に、ドメインモデルを使用することをお勧めします。これは、エンティティとエンタープライズビジネスルールが定義されており、他のものに依存することのないドメインモデルです。 さらに、アプリケーション・ビジネス・ルールが実装されるドメイン・モデルの上のレイヤーを示唆し、ユースケースをコマンド・デザイン・パターンに似たインターフェースに依存するクラスとして実装します。 私の質問は、この最後の層の構成に関するものでした。 – PlusInfinite

関連する問題