我一直在阅读很多关于你们如何组织业务逻辑的文章，很明显，只要它与应用程序中的其他层分离，就没有错误的实现。
我的问题与层的物理实现有关，而不是概念。您希望如何实际实现业务逻辑层的结构？
我倾向于有一个"服务"文件夹，其中包含应用程序每个模块/部门的持久性和查询服务类。
您对业务层的文件夹结构的偏好是什么，因此，如果要从解决方案资源管理器查看它，您倾向于/更喜欢创建哪些文件夹和子文件夹？
编辑：
我问你更喜欢将文件夹标记为什么。我将我的模块文件夹称为"服务"，我也看到它们被标记为"实体助手"。
你在问建筑的基本问题："我有很多逻辑......我该如何构建它？很难简要地回答这样一个一般性的问题，因为许多书籍都写过这个问题的各个方面
基本设计原则：分层、切片、关注点分离、单一责任、高内聚-低耦合等，应该应用于架构的各个层面，而不仅仅是顶层。
"文件夹"对于组织您的解决方案来说并不过分简单。虽然，如果你在一个相对较小的问题中工作，它应该就足够了。考虑到分层并保持业务逻辑的紧密和连贯性，我建议您阅读更多关于 Eric Evans 的 DDD 的信息。
您将在域层中创建业务逻辑，将其与视图(不一定是 Web(、应用程序和基础架构逻辑分离。
查看Microsoft示例，它抓住了 DDD 的本质。 还有Vaughn Vernon DDD的书，他给出了理解它使用的实用方法。