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