分层单体与模块化单体的边界

分层单体（Layered Monolith）：按技术层划分包结构，所有业务能力共享同一部署单元与数据库。优点是上手快、本地调试简单、事务在进程内完成；风险是边界模糊时演变成「大泥球」——改订单逻辑可能误触库存表。

典型分层（概念）

flowchart TB
  UI[Web / API Controller] --> APP[Application Service]
  APP --> DOM[Domain Model]
  DOM --> INF[Infrastructure / JPA]
  INF --> DB[(单一数据库)]

模块化单体（Modular Monolith）

仍在一个进程、一次部署，但按业务能力或限界上下文划分子模块（Maven/Gradle 多模块），模块间通过显式 API 通信，禁止随意跨模块访问对方表。

• shopflow-order、shopflow-inventory、shopflow-payment 模块，共享 shopflow-app 启动器。
• 模块内可继续分层；模块间仅暴露接口（Java interface / 应用服务门面）。
• 为将来拆成独立服务做「排练」：边界清晰后再加网络与注册发现。

代码对比：跨边界访问

// 反例：订单服务直接操作库存表
@Service
class OrderService {
  @Autowired InventoryRepository inventoryRepo; // 跨上下文泄漏
  void placeOrder(...) {
    inventoryRepo.decrement(skuId, qty);
  }
}

// 推荐：通过 inventory 模块公开门面
@Service
class OrderService {
  private final InventoryFacade inventory;
  void placeOrder(...) {
    inventory.reserve(new ReserveCommand(orderId, skuId, qty));
  }
}

SOA、ESB 与微服务的演进脉络

2000 年代前后，面向服务架构（SOA） 强调将企业能力封装为可复用服务，常配合企业服务总线（ESB） 做路由、转换、编排与集中治理。

演进时间线（简化）

timeline
  title 从集中到分布式的常见路径
  2000s : 分层单体 / 大泥球
  2005-2015 : SOA + ESB 集中编排
  2014+ : 微服务 + 轻量消息总线 / API 网关
  近年 : 模块化单体复兴 + 选择性微服务

SOA + ESB 的典型拓扑

flowchart LR
  O[订单系统] --> ESB[ESB 总线]
  I[库存系统] --> ESB
  P[支付系统] --> ESB
  ESB --> T[转换 / 路由 / 编排规则]

微服务的关键转向

• 智能端点， dumb pipe：业务逻辑在服务内；管道尽量简单（HTTP/gRPC、消息中间件），避免 ESB 里堆满业务规则。
• 去中心化数据：每服务自有数据库（或 schema），不再默认「全企业一个库」。
• 独立部署：团队拥有从设计到运行的全生命周期（DevOps）。

微服务收益、成本与适用场景

微服务不是「更先进的单体」，而是用运维与组织复杂度交换独立演进能力。下表帮助你在评审会上说清利弊。

场景决策表

康威定律与团队拓扑

康威定律（Conway's Law）：设计系统的组织，其产生的设计等价于组织内的沟通结构。换言之一一你的架构图最终会像你的组织架构图。

对微服务拆分的含义

• 若订单与库存由同一小队维护，硬拆成两个远程服务只会增加沟通成本，而不会 magically 变快。
• 若支付由合规独立团队负责，payment-service 作为独立部署单元更自然。
• 平台团队提供注册发现、网关、CI 模板，让业务小队专注域逻辑（Team Topologies 中的 Platform / Enabling）。

flowchart TB
  subgraph teamOrder [订单小队]
    OS[order-service]
  end
  subgraph teamInv [库存小队]
    IS[inventory-service]
  end
  subgraph teamPay [支付小队]
    PS[payment-service]
  end
  subgraph platform [平台小队]
    GW[API Gateway]
    REG[注册中心]
  end
  GW --> OS
  GW --> IS
  OS -->|同步 reserve| IS
  PS -->|PaymentCompleted 事件| OS

反模式：组织未拆，服务先拆

两个团队仍共用一个 backlog，却维护六个微服务 — 变更仍需全员协调，却背上分布式排障成本。这叫分布式单体（领域建模、边界上下文与 API 契约 会进一步约束边界）。

何时不应拆微服务

下列信号出现越多，越应推迟物理拆分，优先模块化单体或合并服务。

• 边界不清：Order 与 Inventory 实体互相引用，无法一句话说清谁拥有哪张表。
• 无自动化：没有 CI/CD、容器化、集中日志与链路追踪，却要先上 8 个服务。
• 事务密集：大量跨模块强一致 ACID 需求，拆后只能上重型分布式事务。
• 团队过小：5 人维护 12 个服务，人均运维负担超过业务开发。
• 为技术而拆：「微服务很潮」但流量与组织规模仍适合单体。

渐进路径

1. 模块化单体 — 在进程内练边界与契约。
2. 绞杀者（Strangler） — 新能力在新服务，旧模块逐步下线（演进模式、反模式与架构评审 再展开）。
3. 选择性拆分 — 先拆变化最快或需独立扩缩的上下文（如 Inventory 读多写多）。

下一章进入 领域建模、边界上下文与 API 契约，把「模块/服务边界」落到限界上下文与 OpenAPI。