服务解耦的核心在于严格隔离通信边界：通过独立网络划分业务域、禁止跨域直连、依赖DNS服务发现、专属数据库与事件驱动、网关统一入口及内外网分离，从基础设施层保障松耦合。
服务解耦不是靠“连得上”实现的，而是靠“不该连的坚决不连”来保障。Docker Compose 本身不制造解耦，它只是把你的解耦设计忠实地跑起来——关键在配置逻辑是否体现边界意识。
用独立网络划分通信域
每个业务域（如用户、订单、支付）应有专属内部网络，禁止跨域直连。这不是可选项，是契约底线：
- 在
docker-compose.yml的networks区块中为每个域定义独立 bridge 网络，例如user-net、order-net - 服务只加入自己所属网络：
user-service加入user-net，order-service加入order-net，两者默认不通 - 若需跨域交互（如订单查用户昵称），必须经由网关或消息中间件中转，不能在代码里写
jdbc:postgresql://user-db:5432
靠服务名通信，而非 IP 或端口硬编码
容器间调用必须依赖 Docker 内置 DNS 解析，这是实现松耦合的基础机制：
- 同一网络内的服务，直接用
http://service-name:port访问（如http://auth-service:3000/login） - 确保所有服务都声明
networks，且不在ports下暴露内部端口给宿主机——暴露仅用于外部接入点（如 API 网关） - 禁止在应用代码或配置中写死容器 IP；若发现
172.x.x.x地址，说明设计已退化为紧耦合
用事件驱动替代跨库查询
数据库直连是最常见的隐性耦合源头。解耦必须从数据所有权开始划清界限：
- 每个微服务配专属数据库实例（如
user-db、order-db），不复用同一容器 - 删除所有跨服务 SQL 查询（JOIN / remote SELECT）；需要对方数据时，订阅其发布的事件（如
UserProfileUpdated） - 消息中间件（Kafka / Redis Streams）作为独立 service 编排，所有服务通过服务名连接它，不嵌入 SDK 或本地队列
网关统一入口，隔离内外通信平面
外部请求和内部服务调用必须走不同网络路径，从基础设施层切断越权可能：
- 定义两个网络：
public-net（供 Nginx / API Gateway 使用）、internal-net（供业务服务与 DB 通信） - 网关服务只接入
public-net，并通过internal-net调用后端，但绝不把数据库端口映射到public-net - 数据库服务只接入
internal-net，ports字段留空或仅用expose，确保外部完全不可达
