无Bundle的Symfony 4大型单体项目架构规划问询

作为长期跟Symfony打交道的老玩家，我太懂你从Bundle结构转到无Bundle单体的纠结了——毕竟300个路由、70个控制器的规模，乱搞后期绝对爆炸。下面针对你的三个问题逐个拆解：

1. services.yaml配置：以App命名空间为核心，按业务模块拆分配置 #

首先明确：别再硬模拟Bundle结构了，那是Symfony 3及以前的产物，4+的无Bundle模式就是让你以业务领域为核心划分，而非技术边界。

• 命名空间选择：直接用Symfony默认的App命名空间，把原来的20个Bundle映射成App下的子命名空间，比如原来的AcmeUserBundle对应App\User，AcmeOrderBundle对应App\Order，这样既能复用原来的业务划分逻辑，又完全贴合新规范。
• 服务配置拆分：
  • 主config/services.yaml只保留全局规则，比如默认的App\*自动注册服务（Symfony 4+默认已经配置了App\:的autoconfigure: true和autowire: true，大部分服务不用手动注册）；
  • 每个业务模块的专属服务配置，放到config/packages/{模块名}/services.yaml，比如config/packages/user/services.yaml专门配置用户模块的服务参数、别名、特殊依赖注入规则等。这样既避免主配置文件臃肿，又能保持模块的配置独立性。

2. 服务与控制器目录：按业务领域聚合，选src/{Something}/Service/... #

绝对选后者！核心原因是按业务领域聚合代码，而非按技术类型拆分，这对大型单体应用的维护太重要了：

• 如果用src/Service/{Something}/...，你会发现用户相关的控制器在src/Controller/User/、实体在src/Entity/User/、服务在src/Service/User/，每次找一个模块的代码要跨N个顶层目录，来回切换效率极低；
• 而src/User/Controller/UserController.php、src/User/Service/UserManager.php、src/User/Entity/User.php这种结构，把所有用户模块的代码都收拢在一个目录下，不管是改需求、查Bug还是新人接手，都能快速定位整个模块的所有代码。

而且完全不用担心Symfony的自动配置问题——只要命名空间和目录对应（比如App\User\Service\UserManager），默认的服务自动注册规则会完美适配，不用额外写配置。

3. 特殊组件的目录放置 #

UserAuthenticationProvider #

它属于用户领域的认证逻辑，直接放到src/User/Security/UserAuthenticationProvider.php（或者更直白的src/User/Authentication/UserAuthenticationProvider.php），因为它和用户模块强绑定，放在领域目录下的子目录里，保持代码内聚性。

WebSocketServer #

分两种情况：

• 如果WebSocket是全局通用的基础设施（比如给多个业务模块提供实时通信能力），就放到src/Infrastructure/WebSocket/WebSocketServer.php，用顶层的Infrastructure目录来统一存放这类跨模块的基础服务；
• 如果WebSocket主要服务于特定业务（比如只用于聊天模块），就放到对应业务目录下，比如src/Chat/Infrastructure/WebSocketServer.php，保持业务逻辑的关联性。

内容的提问来源于stack exchange，提问作者Ernestas Stankevičius