4. 业务模块边界定义原则：高内聚低耦合、单一职责、限界上下文

在 Kubernetes 微服务架构中，业务模块边界的定义直接决定了系统的可维护性、可扩展性与部署效率。错误的边界划分会导致服务间过度耦合、变更扩散、部署爆炸等问题。本章围绕三个核心原则——高内聚低耦合、单一职责、限界上下文——展开实战设计方法。

4.1 三大原则概述

4.2 高内聚低耦合：模块内部的凝聚力与模块间的隔离

高内聚要求模块内部的元素（函数、类、数据）共同完成一个明确的目标；低耦合要求模块之间通过稳定的接口通信，减少直接依赖。在 K8s 中，这一原则体现在以下层面：

• Pod 级别：同一 Pod 内的容器共享网络栈和存储卷，适合部署紧密协作的 sidecar 模式（如日志采集、代理转发），但不应将不相关的业务容器混入同一 Pod。
• Service 级别：每个 Service 暴露一组 Pod 的稳定访问入口，Service 之间通过 DNS + 端口解耦，避免硬编码 IP。
• Namespace 级别：通过 NetworkPolicy 实现跨 Namespace 的流量管控，强制模块间仅通过允许的端口通信。

4.3 单一职责：一个服务只做一件事

单一职责原则（SRP）在微服务中的含义是：一个微服务应该只有一个变更理由。在 K8s 中，每个 Deployment 应对应一个独立的业务能力单元。

判断职责是否单一的标准：

1. 数据归属：该服务是否拥有独立的数据库或表？如果多个服务共享同一张表，说明职责未分离。
2. 变更频率：如果两个功能模块的变更频率不同，应拆分为独立服务。
3. 团队归属：如果两个模块由不同团队维护，必须拆分为独立 Deployment。

# 反例：一个 Deployment 包含订单和支付两个容器
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-payment-mixed
spec:
  template:
    spec:
      containers:
      - name: order-service
        image: order:1.0
      - name: payment-service
        image: payment:1.0
# 问题：扩缩容必须同时进行，无法独立升级支付服务

# 正例：两个独立的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  template:
    spec:
      containers:
      - name: order-service
        image: order:1.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      containers:
      - name: payment-service
        image: payment:1.0

4.4 限界上下文：领域驱动的边界划分

限界上下文（Bounded Context）是 DDD 的核心战术模式。它定义了模型应用的边界，在边界内部保持统一的语言和逻辑，边界之间通过上下文映射（Context Map）进行集成。

在 K8s 中，限界上下文与 Namespace 形成天然映射关系：

4.5 三原则协同：边界定义决策流程

在实际项目中，三个原则需要协同使用。以下决策流程可以帮助团队快速确定业务模块边界：

1. 第一步：识别限界上下文 —— 通过事件风暴（Event Storming）或业务流程分析，划分出独立的业务领域边界。
2. 第二步：应用单一职责 —— 在每个限界上下文内部，将变更原因不同的功能拆分为独立的微服务。
3. 第三步：验证高内聚低耦合 —— 检查每个微服务内部的元素是否紧密相关，微服务之间的依赖是否通过 API 契约解耦。
4. 第四步：映射到 K8s 资源 —— 每个限界上下文对应一个 Namespace，每个微服务对应一个 Deployment + Service，跨上下文通信通过 Ingress/Gateway 控制。

4.6 边界定义原则的 SVG 架构图

下图展示了三个原则在 K8s 集群中的协同作用：

4.7 边界定义检查清单

在完成模块边界设计后，使用以下清单进行自检：