1. 课程导论：为什么需要业务模块边界与领域边界？K8s在微服务架构中的角色

1.1 微服务架构的“混沌”困境

当团队从单体架构转向微服务时，往往陷入一种“伪拆分”的泥潭：服务数量激增，但每个服务内部依然耦合着多个业务逻辑，导致修改一个功能需要跨多个服务协调发布。这种缺乏边界的架构会引发以下典型问题：

• 服务爆炸：一个业务功能被拆成 5-8 个微服务，但每个服务职责模糊，互相调用形成网状依赖。
• 部署耦合：修改订单状态需要同时更新支付、库存、物流三个服务，违背了“独立部署”的微服务初衷。
• 数据一致性灾难：业务逻辑分散在多个服务中，事务边界不清晰，导致分布式事务补偿逻辑复杂且易出错。
• K8s 资源浪费：每个微服务都申请独立的 Deployment 和 Service，但实际流量不均，Pod 资源利用率低于 30%。

1.2 业务模块边界 vs 领域边界：概念辨析

在开始设计之前，必须区分两个核心概念：

1.3 K8s 在微服务架构中的角色定位

K8s 不是微服务框架，而是微服务的“基础设施操作系统”。它解决了微服务运行时的弹性、调度、网络和存储问题，但不解决业务边界设计问题。下图展示了 K8s 在微服务架构中的分层角色：

1.4 没有边界设计的 K8s 部署：一个反面案例

假设一个电商系统，团队将“订单创建”拆成了 4 个微服务：order-create、inventory-check、payment-init、notification-send。在 K8s 上的表现如下：

# 错误示例：每个微服务独立部署，但业务边界混乱
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-create
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-create
  template:
    metadata:
      labels:
        app: order-create
    spec:
      containers:
      - name: order-create
        image: order-create:1.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inventory-check
spec:
  replicas: 2
  # ... 类似配置
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-init
spec:
  replicas: 2
  # ... 类似配置
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: notification-send
spec:
  replicas: 1
  # ... 类似配置

问题分析：

• 这四个服务实际上属于同一个业务领域（订单创建），但被拆成了 4 个独立的 Deployment，导致运维复杂度增加 4 倍。
• 当订单流程变更时（例如增加风控检查），需要同时修改 4 个服务的代码并重新部署。
• K8s 的 HPA（水平自动伸缩）无法基于“订单创建”这个业务指标统一扩缩，只能分别配置，容易造成资源碎片。

1.5 正确的边界设计：领域驱动设计（DDD）与 K8s 的映射

本课程的核心方法论是将 DDD 的限界上下文与 K8s 的资源模型对齐。下表展示了从业务领域到 K8s 资源的映射关系：

1.6 本章小结：边界设计的价值

通过本课程，你将掌握以下核心能力：

1. 识别业务领域边界：使用事件风暴（Event Storming）和上下文映射（Context Map）技术，将复杂的业务需求拆分为清晰的限界上下文。
2. 设计业务模块边界：在限界上下文内部，合理划分模块，确保每个模块的职责单一、依赖清晰。
3. K8s 资源映射：将领域设计成果转化为 K8s 的 Namespace、Deployment、Service、ConfigMap 等资源定义。
4. 持续演进：通过 K8s 的 Operator 和 CRD，实现业务边界的自动化管理和动态调整。