我收到了关于这个话题的不同意见，所以我决定来这里问这个问题。我在上写了一个相对较旧的代码库。NET Framework，我必须迁移到它。NET 6与干净的体系结构。
在应用程序层中，我有一个很大的混乱的助手类，它使用了许多服务和其他带有当场实例化逻辑的类。
CacheService CacheService=新的CacheService((
StepExecutior stepExecutior=new StepExecutior((
CacheInvalidator CacheInvalidator=新CacheInvalidator=((
等等。。。
这些类的实现现在应该转移到基础结构层。
因此，对于服务，我在应用层中创建了契约，并在 infrastructure层我关心的是其他类型的类，例如：manager、helpers、invalidator、executor、handler类。(CacheInvalidator、StepExecutor、WorkflowManager、EventHandler( 为这些类添加抽象层的最佳方法是什么？还将它们作为服务，并通过构造函数注入？我应该使用工厂吗？包装？如果能对这个问题有任何见解，我将不胜感激。任何意见，任何文件。就我个人而言，我认为这个类应该完全重写和拆分。 如果这是一个非常愚蠢的问题，我真的很抱歉，我没能找到与我类似的场景，我发现的大多数东西都只是在有两个服务的小项目上，其中添加了抽象层，仅此而已。这是我第一次做这样的事。 提前感谢，我希望这可能会在未来对某人有所帮助！
对于这些其他类(管理器、助手、处理程序…(，您必须做出的第一个决定是：此代码应该转到哪一层？这一切都与商业逻辑有关吗？然后它应该保留在应用程序层中，您可以直接使用这些，也可以通过接口和工厂使用这些。
如果这些类别被认为是"；基础设施"；？你想远离商业逻辑的东西？然后按照您已经描述的方法(应用层中的接口，实现转到基础结构层(。
可能——在遗留代码库中并非不可能——这样的类往往是"；在中间"：一些方面可以被视为业务逻辑，另一些方面则被视为基础设施。那么你应该付出努力，划分类，然后如上所述继续。