分层架构中FileSystemWatcher实现与后台线程管理方案问询

我的系统采用UI、应用层、领域层、基础设施层的分层架构，核心需求是监听输入文件夹的新文件并移动到输出文件夹。UI侧支持新增/移除输入→输出文件夹对：

• 新增时需启动FileSystemWatcher在独立线程监听，回调也在独立线程执行避免阻塞，回调由应用层用例处理器配置，可接入领域对象方法（必要时适配），计划用工厂按输入路径创建IFileSystemWatcher实例
• 移除时需停止FileSystemWatcher线程及所有回调线程，考虑用线程池处理回调

我主要困惑：

1. 线程的创建与管理应放在哪一层？
2. FileSystemWatcher属于哪一层？
3. 上述逻辑的实现细节应归属哪一层？
4. 如何处理并管理产生事件的后台线程？

我设想的IFileSystemWatcher接口如下：

public interface IFileSystemWatcher {
    void StartWatching();
    void StopWatching();
    void RegisterCallback(Action<FileSystemEvent> callback);
}

不确定该接口放在领域层还是应用层，感觉领域层负责文件检测，但可能片面。

分层架构下的职责划分与实现方案 #

1. 先锚定各层核心边界 #

明确分层的核心职责是划分的基础：

• 领域层：只聚焦核心业务规则（比如「新文件必须移动到对应输出目录」），不涉及任何外部依赖（包括文件系统、线程）
• 应用层：编排业务流程，协调领域对象与外部资源，处理具体用例（比如「新增文件夹对→启动监听→触发文件移动逻辑」）
• 基础设施层：实现与外部系统/资源的交互（比如文件系统操作、线程管理、原生FileSystemWatcher调用）
• UI层：仅负责用户交互，调用应用层暴露的用例接口

2. IFileSystemWatcher接口的归属 #

这个接口放在应用层更合理：

• 它定义的是「监听文件系统事件」的能力，属于支撑业务流程的动作，而非核心业务规则
• 领域层不需要感知「监听」这个操作，只需要知道「有新文件要处理」即可，接口暴露给应用层，方便流程编排

3. FileSystemWatcher实现与线程管理的分层 #

• FileSystemWatcher具体实现：放在基础设施层。因为它是直接操作文件系统的工具，属于外部资源交互范畴。这里负责封装.NET原生FileSystemWatcher，处理线程创建、回调线程池调度等底层细节。
• 线程创建与管理：完全由基础设施层负责。应用层只需要调用StartWatching()/StopWatching()，不需要关心线程如何启动、如何终止。比如在基础设施层的实现中：
  • 启动监听时，配置原生FileSystemWatcher在独立线程运行（或利用其内置异步机制）
  • 回调逻辑通过线程池执行，避免阻塞监听线程
  • 停止时，确保原生FileSystemWatcher正确释放资源，终止相关线程

4. 完整流程示例 #

• UI层：用户新增文件夹对，调用应用层AddFolderPair(inputPath, outputPath)用例
• 应用层：
  1. 调用领域层创建/更新FolderMapping业务对象，验证路径合法性等业务规则
  2. 通过工厂从基础设施层获取IFileSystemWatcher实例
  3. 注册回调：回调内调用领域层ProcessNewFile(filePath, outputPath)方法（处理文件移动的业务逻辑）
  4. 调用StartWatching()启动监听
• 基础设施层：
  • FileSystemWatcherImpl实现IFileSystemWatcher，内部封装原生FileSystemWatcher
  • StartWatching()启动监听，设置回调通过线程池执行
  • StopWatching()停止监听、释放资源，确保回调线程完成或终止
• 领域层：ProcessNewFile只处理业务逻辑（比如检查文件合规性），文件移动操作可委托给基础设施层的文件操作接口，保持领域层纯净

5. 后台线程管理的通用原则 #

对于这类长期运行的事件驱动后台任务：

• 应用层负责调度（启动/停止任务），不关心底层线程细节
• 基础设施层负责执行（线程创建、资源管理、任务生命周期维护）
• 用抽象接口隔离应用层与基础设施层，方便测试（比如用Mock实现替代真实文件系统监听）

内容的提问来源于stack exchange，提问作者Patrick Christie