UseCaseの実行を制限したい

Question

質問内容

趣味で学習を兼ねてC#でデスクトップアプリを作っていて、
コードが複雑になってきたのでクリーンアーキテクチャで書き直しているのですが、

例えばRepositoryからデータを読み込んで、UseCaseに応じてDomainで処理を行うとして、
保存UseCaseや読み込みUseCaseの実行時に、他の処理（非同期を含む）を行うUseCaseの実行を制限したいのですが
その処理はどのレイヤーに書いたらいいのでしょうか。

Controllerで入力を制限する場合はUseCaseからControllerにそれを伝えることになると思いますが、
調べた限りController->UseCase->Presenterと一方方向になると思いますし、
Controllerでその制限を実装しなかった場合実行時にDomainでエラーになるので、
Applicationレイヤーで実装すべきかなと思うのですが、そのレイヤーで状態を持っていいのか等、
色々ネットでクリーンアーキテクチャについて調べたのですが混乱しています。

通常UIスレッドで同期的に行えば上記問題は発生しませんが、UseCaseにawaitを含むコードがあるので
処理->UI更新までのUseCase単位での排他制御（実行の制限）をする必要があるといった感じです。

こういう問題は重い処理を行うアプリでは頻出すると思うので、同期処理と非同期な重い処理を分けて、
重い処理（タスク）を管理する仕組みがあるのではないかと思うのですが、
そういった仕組みを作って解決するべきでしょうか。

####### 追記
コードの例です。WPFなのでViewModelでBindingを行っていますが、質問の部分はInteractorの各UseCaseです。
例のためTask.Delayを使っていますが、ProcUseCaseを呼び出した直後にLoadUseCaseを呼び出すとエラーになります。
各UseCaseを排他的に呼び出す処理をInteractorに持たせるか、もしくは非同期な処理を管理するクラスを作るか、
このあたりの設計が分からず悩んでいます。
書いていて思ったのですが後者のほうが簡単かもしれません…

using System;
using System.Threading.Tasks;
using System.Windows;

namespace WpfArchTestApp
{
    internal class Entity
    {
        public string Data
        {
            get { return disposed ? throw new ObjectDisposedException("Entity") : data; }
            set { data = value; }
        }
        private string data;
        private bool disposed = false;
        public void Dispose() { disposed = true; }
    }

    internal class Repository
    {
        public async Task<Entity> Load()
        {
            await Task.Delay(1000);
            return new Entity { Data = "TestStringData" };
        }

        public async Task Save(Entity _)
        {
            await Task.Delay(1000);
        }
    }

    internal class DomainService
    {
        public static async Task HeavyWork(Entity entity)
        {
            for (int i = 0; i < entity.Data.Length; ++i)
            {
                for (int j = 0; j < entity.Data.Length; ++j)
                {
                    if (entity.Data[i] >= entity.Data[j]) continue;
                    char[] charArray = entity.Data.ToCharArray();
                    charArray[j] = entity.Data[i];
                    charArray[i] = entity.Data[j];
                    entity.Data = new string(charArray);
                    await Task.Delay(20);
                }
            }
        }
    }

    internal class Interactor
    {
        public event EventHandler DataUpdated;
        public string Data { get { return entity == null ? "" : entity.Data; } }

        private readonly Repository repository;
        private Entity entity;

        public Interactor(Repository repository)
        {
            this.repository = repository;
        }

        public async void LoadUseCase()
        {
            if (entity != null)
            {
                entity.Dispose();
                entity = null;
            }
            entity = await repository.Load();
            DataUpdated?.Invoke(this, EventArgs.Empty);
        }

        public async void ProcUseCase()
        {
            if (entity == null) return;
            await DomainService.HeavyWork(entity); // 他のUseCaseが呼ばれるとエラー
            DataUpdated?.Invoke(this, EventArgs.Empty);
        }

        public async void SaveUseCase()
        {
            if (entity == null) return;
            await repository.Save(entity);
            entity.Dispose();
            entity = null;
            DataUpdated?.Invoke(this, EventArgs.Empty);
        }
    }

    internal class MainWindowViewModel : VMCommon.ViewModelBase
    {
        public VMCommon.DelegateCommand LoadCommand { get; }
        public VMCommon.DelegateCommand ProcCommand { get; }
        public VMCommon.DelegateCommand SaveCommand { get; }
        public string Data
        {
            get { return data; }
            private set
            {
                if (data == value) return;
                data = value;
                RaiseProeprtyChanged();
            }
        }

        private readonly Interactor interactor;
        private string data;

        public MainWindowViewModel()
        {
            Repository repository = new Repository();
            interactor = new Interactor(repository);
            LoadCommand = new VMCommon.DelegateCommand(_ => interactor.LoadUseCase());
            ProcCommand = new VMCommon.DelegateCommand(_ => interactor.ProcUseCase());
            SaveCommand = new VMCommon.DelegateCommand(_ => interactor.SaveUseCase());
            interactor.DataUpdated += Interactor_DataUpdated;
        }

        private void Interactor_DataUpdated(object sender, EventArgs e)
        {
            Data = interactor.Data;
        }
    }

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            DataContext = new MainWindowViewModel();
        }
    }
}

Comments

[dodox86]

※これは現在のご質問内容に対する非難ではありません。

私の個人的な主観も大きいですが、「クリーンアーキテクチャ」と言うもの自体がそれほどまだメジャーな印象が無いので、C#の実装にまで踏み込んで良し悪しを討議できるような活発な質疑応答は少し難しいように思います。もちろん、既に習熟、あるいは実務に適用されようとしている方からの有効な回答はあるかもしれませんが。それでも、質問者tonicaさんがどんなコードをそれぞれのレイヤーに当てはめて書こうとしているか具体例を明示すれば、多少離れたとしても有用な質問、回答になり得るかと思います。（個人的には興味ある部分です）

[tonica]

私自身もクリーンアーキテクチャ自体をまだよく理解しておらず、ネットで調べながら見様見真似で実装していまして、私としてはアプリのコードを見やすく保守しやすく整理できればそれでいいのですが、クラス分けの指針がわからず、クリーンアーキテクチャのようなレイヤーで分けて見ようと思い〇〇Repositoryなど機能毎に現在整理しています。
GUIのアプリでは非同期処理を行う場面も多くあると思いますし、その時にUI操作によって起こる処理のうち排他的に実行（または中断）しなければいけないものがある場合に、ViewやControllerを含めどのように設計すればいいのか、というのが質問の趣旨になります。すみません、質問時に整理できていなかったかもしれません。

[BluOxy]

非同期処理は何を行うために使っているのでしょうか。データベースアクセスでしょうか。もしくは Web API やソケット通信のような何か外部と通信しているのでしょうか。もしくはただ時間がかかる計算処理を行っているのでしょうか。

[tonica]

ただ時間がかかる処理です。ピクセル一つ一つを処理する画像処理のような感じです。同期処理にするとウィンドウごと固まるので非同期にしています。

[BluOxy]

リポジトリで行っている async/await も同じ理由で非同期にしているのでしょうか。実装を濁しているのかわかりませんが、Save は必要でしょうか。

[BluOxy]

リポジトリの Load で新しい Entity を生成しているだけのようなので、そもそもリポジトリは必要でしょうか。もしアプリケーション外とやり取りをしていないなら必要でないと思います。

[tonica]

説明が足りずすみません、repositoryでは実際にはファイルの読み書き・パースを行なっています。データを圧縮して保存しているため、解凍・パースに数秒かかるので非同期にしています。
質問の部分はUseCaseの部分なので、Entityに対する処理やアプリ外との入出力は例として書いています。Saveが空なのもその為です。

Answer 1

保存UseCaseや読み込みUseCaseの実行時に、他の処理（非同期を含む）を行うUseCaseの実行を制限したい

ユースケースは通常そのような実行を制限するために修正しないといけないケースはないと思います。
あくまでビジネスロジックの変更があったときに限りユースケースを修正するようにしないとユースケースの責務の範疇を超えてしまいます。

今回はユースケースの実体(Interactor) が Entity を持っていることでユースケースがユースケース以上のことをしているため制限が必要になっていますが、それを変えれば良いはずです。

Entity は一般的に Repository から生成されることが多いです。Entity を作成するための元データはデータベースやWeb API経由で取得することが多いです。

つまり、永続的なデータはデータベースを管理するDBMS（例えばSQL Server）や外部のサーバーアプリケーションで持つことが一般的です。排他制御もそこで行われます。

repositoryでは実際にはファイルの読み書き・パースを行なっています。データを圧縮して保存しているため、解凍・パースに数秒かかるので非同期にしています。

ということはファイルが永続的なデータになると思います。
複数のスレッドから非同期で同時に書き込まれる場合はこの場合 Repository で排他制御を行うのが適切だと思います。
SemaphoreSlim を使って Save メソッドに対して排他制御を行いましょう。

同期処理にするとウィンドウごと固まるので非同期にしています。

時間のかかる処理だけ非同期で処理するのは問題ありませんが、同一の Entity の参照に対して複数のスレッドから同時に書き込まれる設計にしないよう気を付けてください

他に気になる点

1.Interactor が Repository の実体に依存しているのでこれ等ソースコードの実装はクリーンアーキテクチャではなくレイヤードアーキテクチャに近いと思います。

2.Entity 自体の振る舞いが Dispose メソッド1つしかないのでドメイン貧血症になっています。データベースや WebAPI など外の都合に影響されないなら DomainService をわざわざ作らずに下記のようにするのが十分な気もしますが、いかがでしょう。

// 消す
// internal class DomainService { }

internal class Entity
{
    public string[] Data
    {
        get { return disposed ? throw new ObjectDisposedException("Entity") : data; }
        set { data = value; }
    }
    private string[] data;
    private bool disposed = false;
    public void Dispose() { disposed = true; }

    public async Task<string> HeavyWork()
    {
        for (int i = 0; i < Data.Length; ++i)
        {
            for (int j = 0; j < Data.Length; ++j)
            {
                if (Data[i] >= Data[j]) continue;
                char[] charArray = Data.ToCharArray();
                charArray[j] = Data[i];
                charArray[i] = Data[j];
                Data = new string(charArray);
                await Task.Delay(20);
            }
        }
    }

}

3.Entity が Dispose を持っているのも何だか Entity 以上のことをしているように思います。もし Image のようなリソースを持っているのであれば Entity の外（アプリケーションやフレームワーク、リポジトリなど）で生成したリソースをDIで受け取るのが適切だと思います。リソースを破棄するときも Entity の外 (生成したとき同じクラス)で行います。

internal class Entity
{
    public Image Image { get; }

    public Entity(Image image)
    {
        Image = image;
    }
}


public class Program
{
    public void Main()
    {
        var image = new Image();
        var entity = new Entity(image);

        // TODO: 業務ロジックを書く

        // 必要がなくなったら Dispose する
        image.Dispose();
    }
}

4.Presenter クラスがありませんが、DataUpdated は Interactor ではなくそちらで持つのが適切と思います。

5.規模が大きくなかったり、単体テストなどを考えていないなら今のようにインターフェースが存在しない実装で不満はないのかもしれませんが、各々のクラスが密結合になっているのでインターフェース等を使って疎結合にした方が機能変更には強くなります。

Comments

[BluOxy]

クリーンアーキテクチャに関しては私も疎い部分がありますので、気になる点があればコメントで書いていただければ嬉しいです

[tonica]

回答ありがとうございます。
ご指摘等納得する部分が多いのですが、私自身まだ設計に関する理解が足らない部分が多く、
整理していますのでまた後日返信・解決等をさせていただきます。