终结强耦合梦魇：基于Composer构建松散的领域驱动架构

先明确一个核心观点：Composer本身并不解决强耦合问题，它更像一面镜子，会把你架构中已有的耦合设计放大。真正要在微服务架构里终结强耦合的梦魇，靠的是服务边界划分、通信契约与依赖隔离这三板斧。而Composer，是其中唯一能帮你守住“依赖隔离”这条底线的工具。

为什么在 composer.json 里 require 另一个服务就等于埋雷

一个典型的错误场景是这样的：在 user-service 里执行了 composer require pizzup/order-service。之后，开发者就能在用户服务里直接 new OrderService()，甚至调用它的私有方法，或者读写它的数据库迁移文件。

这根本不是代码复用，而是一种紧耦合的“绑架”。一旦 order-service 升级了 PHP 版本、改了命名空间、或者删掉了某个 DTO 类，user-service 的 composer install 就会立刻失败，整个 CI 流程直接中断。

问题的根源在于，Composer 的 require 指令会把目标包的全部代码——包括 src/、tests/、migrations/ 等目录——都拉进当前服务的 vendor 目录，并纳入自动加载范围。它可不会帮你区分什么是“接口”，什么是“实现”。

正确的做法应该是怎样的呢？

• 契约先行：所有跨服务调用，必须走明确定义的契约。无论是 HTTP 接口（用 OpenAPI 规范定义）、消息事件（通过 Schema Registry 管理），还是共享的 DTO 包。
• 禁止直接依赖：绝对不允许在 A 服务的 composer.json 中直接 require B 服务的主代码包。
• 独立共享包：如果确实有逻辑需要复用，就把它抽离成一个独立的私有包。比如 pizzup/dto-order，这个包里只包含像 OrderCreatedEvent 这样的不可变数据结构。
• 严格限定命名空间：这个 DTO 包的 autoload 配置必须严格限定，例如 "Pizzup\Dto\Order\": "src/Order/"，禁止映射到根目录或过于宽泛的全局命名空间。

如何用 repositories + version constraint 控制领域边界

不过，私有包也不是万能的。想象一下这个场景：pizzup/user-dto 发布了 v2.0 版本，修改了 UserProfile 的字段结构，而 pizzup/notification-service 还依赖着 v1.3 版本。这时，反序列化失败或者字段丢失的问题就来了。

指望“大家自觉升级”是靠不住的，必须依靠 Composer 的版本约束机制来强制收敛：

• 精确版本约束：在 notification-service 的 composer.json"pizzup/user-dto": "^1.3"，而不是模糊的 "^1.0" 或者危险的 "dev-main"。
• 语义化标签：私有 Git 仓库必须打上语义化版本标签（如 v1.3.0），不能只推分支代码。
• CI 流程检查：在 CI 流程中加入检查步骤，例如用命令 composer show pizzup/user-dto --format=json | jq '.version' 来验证实际安装的版本是否符合预期。
• 隔离测试代码：DTO 包自身应该禁用 autoload-dev，避免其测试类被意外加载到生产环境中。

这里提一下性能影响：使用私有 VCS 仓库确实会略微拖慢 composer update 的速度（因为需要克隆仓库元数据），但日常的 composer install 不受影响——它只读取 composer.lock 和本地缓存。

autoload 的 PSR-4 配置怎么写才不越界

一个常见的错误配置是："App\": "src/"。看起来简洁，实则暗藏风险。一旦有人把订单服务的逻辑文件放进了 src/Order/ 目录，却忘了修改命名空间，这个类就会被用户服务自动加载——而它根本不应该存在于这个服务中。

正确的做法，是让 autoload 配置成为服务边界的“守门员”：

• 专属命名空间映射：每个服务的 composer.json 中，autoload 只映射自己明确拥有的命名空间，例如 "Pizzup\UserService\": "src/"。
• 禁止宽泛前缀：禁止使用通配符或过于宽泛的前缀，比如 "Pizzup\" 或 "App\"。
• DTO 包严格一致：DTO 包的 autoload 配置必须与包名完全一致，如 "Pizzup\Dto\User\": "src/User/"，并且这个包不应该声明任何其他命名空间。
• 优化后检查：执行 composer dump-autoload --optimize 之后，可以检查一下 vendor/composer/autoload_psr4.php 文件，确认里面没有冗余或错误的映射关系。

这里有个容易踩的坑：在本地开发时，为了图省事使用 composer dump-autoload -a（即 classmap 模式）来绕过 PSR-4 的检查，结果导致上线后类找不到。这其实恰恰说明 autoload 配置本身就有缺陷，而不是环境问题。

CI/CD 中 composer install 的执行时机很关键

一个典型的错误是：在 CI 流水线的一开始，就在根目录全局运行 composer install，然后才 checkout 具体的服务子目录（比如 user-service）。结果就是，整个单体仓库的所有依赖都被装进了 vendor，导致构建镜像体积暴涨、启动变慢、安全扫描的告警数量也翻倍。

真正实现松散架构的落地点，在于构建的粒度：

• 服务目录内安装：每个服务的 CI job，必须先用 cd 命令进入自身的目录，然后再执行 composer install --no-dev --optimize-autoloader。
• 精准代码拉取：在 Dockerfile 中，执行 COPY . /app 之前，应该先通过 git submodule update --init 或 git sparse-checkout 等方式，确保只拉取当前服务相关的代码。
• 根目录陷阱：禁止在项目根目录放置一个“统一管理”用的 composer.json，那不过是单体架构思维在微服务时代的幻觉。
• 预配置认证：如果使用了私有包，CI runner 必须预先配置好 auth.json，否则 composer install 会在私有仓库的认证环节卡住，最终超时失败。

最后，还有一个最常被忽略的点：不同的服务可能会依赖有冲突的 PHP 扩展（比如一个需要 ext-amqp，另一个需要 ext-redis）。它们必须构建在各自定制的 PHP 基础镜像上。Composer 虽然管不了扩展，但它往往是第一个暴露出这个问题的环节。