DDD関係なくても大丈夫ですよ！案1としては、1つのユースケースクラスからある程度責務を独立させられそうなオブジェクトを切り出します。 例えば、データAを取得する処理はDataAFetcher、変換する処理はDataAConverter…という風に(fetcherのネーミングは微妙な気もしますが一旦例として…) これはprivateメソッドで切り出すことは多いと思いますが、それをすると1クラスが多数のprivateメソッドで膨らんでしまいます。 そうではなくデータAを取得するという責務を持ったクラスして切り出してしまうことで、クラスの凝集度が上がり保守性が高まります。 特にテストはやりやすくなり、それらの独立したクラスそれぞれで単体テストを行い、ユースケースクラスはそれらを組み合わせる観点のテストだけ書けばよくなります。(余談ですが)テストのしやすさを追求することは、良い設計を追求することにも結果としてつながるという好循環が生まれます。 この独立させたクラスは、ユースケース層内オブジェクトという位置づけがよいでしょう。プレゼンテーション層から呼ばれるものはユースケースクラスで、ユースケースから呼ばれる用途限定の独立クラスという位置付けです。 階層化するために、ユースケースを複数呼ぶ方向性もありますが、凝集度を上げられないのであまりお勧めしません。 もう1案は、CQRSの検討です。概要、検討観点は以下のブログに書いたので、参考にしてみてください。 https://little-hands.hatenablog.com/entry/2019/12/02/cqrs