Hexagonal 架构把 8 年遗留 monolith 重构的 6 个月复盘:从三层架构到 Domain Core + Ports + Adapters + 12 条架构演进纪律

2025 年 11 月,我接手了一个 8 年历史的电商订单系统重构项目。原系统是个典型的 Java 单体,32 万行代码,90% 业务逻辑混在 Controller 和 Service 里,跟 MySQL、Redis、外部支付、物流、风控 6 个外部系统强耦合。我们决定用 Hexagonal Architecture(六边形架构,又名端口与适配器)重构这个 monolith,6 个月的实战让我对"架构演进"有了全新的理解。这篇是完整的重构复盘,从最初的"为重构而重构"到最终"业务驱动的渐进式演进",中间踩过的坑、走过的弯路、做对的决策,都在这里。

这套 Hexagonal 架构落地经验适用于所有 5 年以上的遗留系统重构。我们最终把订单核心域从 Controller-Service-DAO 三层架构演进到"Domain Core + Ports + Adapters"的清晰分层,核心域代码可以无依赖运行测试,数据库从 MySQL 切到 PostgreSQL 只改了一个 Adapter,业务功能开发效率提升 3 倍。

项目背景:订单系统的技术债务

这套系统的核心痛点是"想改一个字段都要回归一整套测试"——业务逻辑、数据持久化、外部调用全部纠缠在一起。任何一次改动都要小心翼翼,生怕一个细节崩溃整个支付链路。这就是我们决定下重药的根本原因。

事故时间线:为什么必须重构

第一步:理解 Hexagonal 架构

Hexagonal Architecture(2005 年 Alistair Cockburn 提出)
核心思想:把"业务逻辑"和"外部世界"彻底隔离

┌─────────────────────────────────────────┐
│            外部世界(Adapters)           │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  │
│  │   HTTP  │  │  Kafka  │  │   CLI   │  │
│  └────┬────┘  └────┬────┘  └────┬────┘  │
│       │            │            │        │
│  ┌────▼────────────▼────────────▼────┐  │
│  │       Input Ports (interfaces)    │  │
│  └────────────────┬──────────────────┘  │
│                   │                      │
│         ┌─────────▼─────────┐           │
│         │   Domain Core     │           │
│         │   (业务逻辑核心)   │           │
│         └─────────┬─────────┘           │
│                   │                      │
│  ┌────────────────▼──────────────────┐  │
│  │      Output Ports (interfaces)    │  │
│  └────┬────────────┬────────────┬────┘  │
│       │            │            │        │
│  ┌────▼────┐  ┌────▼────┐  ┌────▼────┐  │
│  │  MySQL  │  │  Redis  │  │ Payment │  │
│  └─────────┘  └─────────┘  └─────────┘  │
│            外部世界(Adapters)           │
└─────────────────────────────────────────┘

Hexagonal 的精髓是"领域核心不知道外部世界存在,只通过 Port 接口和外面打交道"。这样,数据库、消息队列、HTTP 框架都成了可替换的"外设",核心业务逻辑可以独立测试、独立演进。这是 DDD 战术设计的工程落地形态。

第二步:核心域建模

// 领域核心:订单聚合根
package com.shop.order.domain;

public class Order {
    private OrderId id;
    private CustomerId customerId;
    private List<OrderLine> lines;
    private OrderStatus status;
    private Money totalAmount;
    private Instant createdAt;

    // 业务行为
    public void placeOrder() {
        if (lines.isEmpty()) {
            throw new EmptyOrderException();
        }
        if (status != OrderStatus.DRAFT) {
            throw new InvalidStatusTransition();
        }
        this.status = OrderStatus.PLACED;
        this.totalAmount = calculateTotal();
        DomainEvents.publish(new OrderPlacedEvent(this));
    }

    public void cancel(CancellationReason reason) {
        if (status == OrderStatus.SHIPPED) {
            throw new CannotCancelShippedOrder();
        }
        this.status = OrderStatus.CANCELLED;
        DomainEvents.publish(new OrderCancelledEvent(this, reason));
    }

    public void confirmPayment(PaymentId paymentId) {
        if (status != OrderStatus.PLACED) {
            throw new InvalidStatusTransition();
        }
        this.status = OrderStatus.PAID;
        DomainEvents.publish(new OrderPaidEvent(this, paymentId));
    }

    private Money calculateTotal() {
        return lines.stream()
            .map(OrderLine::subtotal)
            .reduce(Money.ZERO, Money::add);
    }
}

// 注意:Order 不依赖任何外部框架
// 不依赖 Spring、JPA、Jackson、Kafka
// 纯粹的 Java + 业务概念

第三步:定义 Ports(端口接口)

// Input Port(驱动端口):外部如何驱动核心
package com.shop.order.domain.port.in;

public interface PlaceOrderUseCase {
    OrderId execute(PlaceOrderCommand command);
}

public interface CancelOrderUseCase {
    void execute(OrderId orderId, CancellationReason reason);
}

public interface QueryOrderUseCase {
    OrderView findById(OrderId id);
    List<OrderView> findByCustomer(CustomerId customerId);
}

// Output Port(被驱动端口):核心如何调用外部
package com.shop.order.domain.port.out;

public interface OrderRepository {
    void save(Order order);
    Optional<Order> findById(OrderId id);
    List<Order> findByCustomer(CustomerId customerId);
}

public interface PaymentGateway {
    PaymentInitResult initiate(PaymentRequest request);
    PaymentStatus query(PaymentId id);
}

public interface NotificationSender {
    void sendOrderConfirmation(Order order);
    void sendCancellationNotice(Order order, CancellationReason reason);
}

// 关键:Port 都是接口,定义在 domain 包内
// 实现在 adapter 包,可以随意替换

第四步:应用服务层(Use Case 实现)

// Application Service:协调 Domain 和 Port
package com.shop.order.application;

@UseCase  // 自定义注解,标识"用例"
public class PlaceOrderService implements PlaceOrderUseCase {

    private final OrderRepository orderRepo;
    private final InventoryService inventoryService;
    private final PaymentGateway paymentGateway;
    private final NotificationSender notifier;

    public PlaceOrderService(
        OrderRepository orderRepo,
        InventoryService inventoryService,
        PaymentGateway paymentGateway,
        NotificationSender notifier
    ) {
        this.orderRepo = orderRepo;
        this.inventoryService = inventoryService;
        this.paymentGateway = paymentGateway;
        this.notifier = notifier;
    }

    @Override
    @Transactional
    public OrderId execute(PlaceOrderCommand command) {
        // 1. 库存预占
        inventoryService.reserve(command.getLines());

        // 2. 构造领域对象
        Order order = Order.create(
            command.getCustomerId(),
            command.getLines()
        );

        // 3. 执行领域行为
        order.placeOrder();

        // 4. 持久化(通过 Port)
        orderRepo.save(order);

        // 5. 异步通知(不阻塞主流程)
        CompletableFuture.runAsync(() ->
            notifier.sendOrderConfirmation(order)
        );

        return order.getId();
    }
}

// 这里的 PlaceOrderService 只依赖 Port 接口
// Adapter 实现(MySQL Repo、HTTP Payment、Email Notifier)注入进来

第五步:Adapter 实现(基础设施层)

// Persistence Adapter:JPA 实现 OrderRepository
package com.shop.order.adapter.out.persistence;

@Component
public class JpaOrderRepository implements OrderRepository {

    private final OrderJpaRepository jpaRepo;
    private final OrderMapper mapper;

    @Override
    public void save(Order order) {
        OrderEntity entity = mapper.toEntity(order);
        jpaRepo.save(entity);
    }

    @Override
    public Optional<Order> findById(OrderId id) {
        return jpaRepo.findById(id.getValue())
            .map(mapper::toDomain);
    }
}

// HTTP Adapter:支付网关
@Component
public class StripePaymentGateway implements PaymentGateway {

    private final StripeClient client;

    @Override
    public PaymentInitResult initiate(PaymentRequest request) {
        StripePaymentIntent intent = client.createIntent(
            request.getAmount(),
            request.getCurrency()
        );
        return new PaymentInitResult(
            PaymentId.of(intent.getId()),
            intent.getClientSecret()
        );
    }
}

// REST Adapter:Web 入口
@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final PlaceOrderUseCase placeOrderUseCase;

    @PostMapping
    public ResponseEntity<OrderId> place(@RequestBody PlaceOrderRequest req) {
        OrderId id = placeOrderUseCase.execute(req.toCommand());
        return ResponseEntity.ok(id);
    }
}

第六步:模块物理隔离

order-service/
├── order-domain/        # 核心业务,无任何框架依赖
│   ├── model/           # 聚合根、值对象、领域事件
│   ├── port/in/         # 用例接口
│   └── port/out/        # 基础设施接口
├── order-application/   # 应用服务,只依赖 domain
│   └── service/
├── order-adapter-web/   # HTTP 入口
│   ├── rest/
│   └── grpc/
├── order-adapter-persistence/  # MySQL/JPA
├── order-adapter-payment/      # 支付网关
├── order-adapter-messaging/    # Kafka
└── order-bootstrap/     # Spring Boot 启动器

# 用 Gradle 模块依赖严格控制
# order-domain:不允许依赖任何其他模块
# order-application:只能依赖 order-domain
# order-adapter-*:只能依赖 order-domain
# order-bootstrap:把所有 adapter 组装起来

问题本质:Hexagonal 的核心价值

性能与可维护性对比

修法 1:渐进式迁移而非一次重写

// 错误做法:推翻重写,6 个月内停止所有新功能
// 正确做法:Strangler Fig Pattern(绞杀者模式)

// 1. 新功能直接用 Hexagonal 写
// 2. 老功能按"读多写少"先重构(风险低)
// 3. 每个模块独立迁移,带完整回归测试
// 4. 老代码外面包一层 Adapter,逐步切流

// 双写过渡:老 Service 和新 UseCase 同时跑
@RestController
public class OrderController {
    private final LegacyOrderService legacyService;  // 老代码
    private final PlaceOrderUseCase newUseCase;       // 新代码

    @PostMapping("/api/orders")
    public OrderId place(@RequestBody PlaceOrderRequest req) {
        if (featureFlag.isEnabled("hexagonal-order-create", req.getCustomerId())) {
            return newUseCase.execute(req.toCommand());
        } else {
            return legacyService.createOrder(req);
        }
    }
}

// 灰度策略:1% → 5% → 25% → 50% → 100%
// 每步停留 1-2 周,观察业务指标和异常率

修法 2:领域事件解耦

// 老代码:订单创建后直接调用 8 个外部系统
public void createOrder(Order order) {
    save(order);
    inventoryService.deduct(...);
    paymentService.initiate(...);
    notificationService.send(...);
    couponService.consume(...);
    pointsService.award(...);
    analyticsService.record(...);
    recommendService.update(...);
}
// 8 个调用,任一失败都得回滚或重试,极复杂

// 新代码:发布领域事件,各自订阅
public void placeOrder() {
    this.status = PLACED;
    DomainEvents.publish(new OrderPlacedEvent(this));
}

// 各个子系统订阅
@EventListener
public class InventoryReducer {
    public void on(OrderPlacedEvent event) {
        inventoryService.deduct(event.getLines());
    }
}

@EventListener
public class PointsAwarder {
    public void on(OrderPlacedEvent event) {
        pointsService.award(event.getCustomerId(), event.getAmount());
    }
}

// 用 Spring Application Events + 事务事件发布
// 或 Kafka outbox pattern 跨进程

修法 3:防腐层(Anti-Corruption Layer)

// 老系统有个"用户中心",字段命名奇葩
// 不能让脏概念污染新核心域

// 防腐层:专门做翻译
@Component
public class UserAclAdapter implements CustomerLookup {

    private final LegacyUserClient legacyClient;

    @Override
    public Customer findById(CustomerId id) {
        // 调用老系统
        LegacyUserDto legacy = legacyClient.getUserInfo(id.getValue());

        // 翻译成新核心域概念
        return new Customer(
            CustomerId.of(legacy.getUid()),
            CustomerName.of(legacy.getRealName() != null ? legacy.getRealName() : legacy.getNickName()),
            new EmailAddress(legacy.getEmailAddr() != null ? legacy.getEmailAddr() : ""),
            VipLevel.fromLegacyCode(legacy.getVipLvl())
        );
    }
}

// 核心域只看到干净的 Customer 概念
// 老系统怎么乱都和新代码无关

修法 4:CQRS 读写分离

// 写模型:领域聚合,严格规则
public class Order {
    // 业务行为,状态机
}

// 读模型:扁平化,贴近 UI
public class OrderListView {
    private String id;
    private String customerName;     // 反规范化字段
    private BigDecimal totalAmount;
    private String statusLabel;       // "已支付" 而非 PAID
    private String shippingAddress;
    private List<String> productImages;
}

@Service
public class OrderQueryService {

    private final JdbcTemplate jdbc;  // 直接 SQL,不走 Repository

    public List<OrderListView> listForCustomer(CustomerId id) {
        return jdbc.query(
            "SELECT o.id, c.name AS customer_name, ... " +
            "FROM orders o LEFT JOIN customers c ON o.customer_id = c.id " +
            "WHERE o.customer_id = ? ORDER BY o.created_at DESC LIMIT 100",
            new Object[]{id.getValue()},
            new OrderListViewRowMapper()
        );
    }
}

// 写走 Domain + Repository,读走原生 SQL
// 性能和清晰度兼得

修法 5:领域服务 vs 应用服务

// 容易混淆的两个概念

// Domain Service(领域服务):跨聚合的业务规则
package com.shop.order.domain.service;

public class PricingService {
    // 计算价格涉及商品、优惠券、会员等级,跨多个聚合
    public Money calculate(Order order, Coupon coupon, VipLevel vip) {
        Money base = order.calculateSubtotal();
        Money afterCoupon = coupon.applyTo(base);
        Money afterVip = vip.discount(afterCoupon);
        return afterVip;
    }
}

// Application Service(应用服务):用例编排
package com.shop.order.application;

public class PlaceOrderService implements PlaceOrderUseCase {
    public OrderId execute(PlaceOrderCommand cmd) {
        // 编排:1.查商品 2.查优惠券 3.调 Domain Service 算价 4.保存
        // 没有业务逻辑,只是 orchestration
    }
}

// 区别
// Domain Service:有业务规则,可能被多个 Use Case 复用
// Application Service:无业务规则,只编排

决策树:何时该用 Hexagonal

我们立的 12 条 Hexagonal 工程纪律

1. Domain 模块零外部依赖,不依赖 Spring/JPA/Jackson;
2. Port 接口定义在 domain,实现在 adapter,严禁倒置;
3. 每个聚合根独立持久化,跨聚合更新走领域事件;
4. 外部脏概念用防腐层翻译,不能进入核心域;
5. Use Case 一个公有方法,职责单一;
6. 事务边界在 Application 层,Domain 内不写 @Transactional;
7. 读写分离,复杂查询走原生 SQL;
8. 领域事件用接口订阅,不直接调用;
9. 渐进式迁移,Strangler Fig,灰度切流;
10. 单测必须能在 5 秒内跑完所有 Domain 用例;
11. 模块依赖在构建时强制检查(ArchUnit/Konsist);
12. 新人入职第一周读懂 Domain 包,第二周做 Adapter 题。

引申一:Hexagonal vs DDD vs Clean Architecture

这三个概念经常被混用,实际上各有侧重。DDD 是方法论,Hexagonal 是架构形态,Clean Architecture 是 Hexagonal 的演进版。DDD 关注"如何对业务建模",通过聚合、值对象、领域事件等战术工具组织代码。Hexagonal 关注"如何隔离业务和基础设施",用 Port-Adapter 实现依赖反转。Clean Architecture 由 Uncle Bob 在 2012 年提出,在 Hexagonal 基础上明确了"依赖方向只能向内",从外到内是 Frameworks → Interface Adapters → Use Cases → Entities。三者并不冲突,实际项目中我们用 DDD 做建模、用 Hexagonal 做物理隔离、用 Clean Architecture 的依赖规则约束代码。这种组合是 2026 年企业级 Java/Go 项目最主流的架构形态,值得每个架构师深度掌握并能根据业务场景灵活组合应用。

引申二:Hexagonal 在微服务中的应用

很多人以为 Hexagonal 只适用于单体,实际上微服务里每个服务都应该是一个 Hexagonal 结构。微服务边界 = Bounded Context,服务内部 = Hexagonal 分层。我们公司 60 多个微服务,每个都有 domain/application/adapter 三层目录,新人到任何一个服务都能快速上手。跨服务调用走 HTTP/gRPC Adapter,服务内部业务逻辑零网络依赖。这种统一架构让微服务团队的人员流动成本下降 70%,服务间技术债务也更可控。微服务和 Hexagonal 不是二选一,而是 1+1 大于 2 的关系,所有服务采用统一 Hexagonal 模板是规模化微服务团队的最佳实践。

引申三:架构演进的非技术因素

架构重构最难的不是技术,而是"人和组织"。我们这次 6 个月重构,40% 时间花在技术,60% 时间花在"说服业务方接受短期效率下降"、"协调跨团队的接口对齐"、"培训老员工新模式"。一个常见误区是"工程师觉得新架构好就强推",结果业务方抱怨"新功能为什么变慢了",一线开发抱怨"为什么要写这么多 Mapper 转换"。我们的经验是:重构必须有"业务故事"——"过去因为耦合每月 5 起 P0 事故,业务损失 X 万,重构后能降到 1 起以下"。把技术语言翻译成业务语言,争取高层支持,定期向业务方汇报里程碑。这种"技术管理"能力比代码能力更稀缺,也是架构师真正的价值所在。

引申四:测试金字塔在 Hexagonal 下的重塑

传统三层架构的测试一般是 30% 单测 + 60% 集成测试 + 10% E2E,因为单测难写。Hexagonal 下测试金字塔重塑为 70% 单测 + 25% 集成测试 + 5% E2E。Domain 单测不需要 Spring 上下文,纯 Java mock 就能跑,毫秒级响应。Application 单测用 mock 的 Port 接口,验证用例逻辑。集成测试只验 Adapter 实现是否符合 Port 契约,用 TestContainers 跑真实数据库。E2E 只保留几条关键链路验证。整个测试矩阵跑完从 30 分钟降到 4 分钟,CI 反馈速度提升 7 倍。这是 Hexagonal 给工程效率带来的最大收益,值得每个团队优先建设。

引申五:架构决策记录(ADR)

重构过程中最容易忘的是"为什么我们当初这么决定"。我们建立了 ADR(Architecture Decision Record)制度,每个重大决策写一份 markdown,记录"背景、可选方案、选择哪个、为什么、有什么 trade-off"。6 个月下来积累了 47 份 ADR,任何新人或半年后的自己都能快速理解"为什么这里要写防腐层"、"为什么不直接用 JPA Entity 当聚合根"。ADR 是组织级架构能力沉淀的核心载体,Spotify、Netflix、Thoughtworks 都有完整的 ADR 实践。这是架构师从"个人英雄"到"组织赋能"必须建立的能力,值得每个有志于成为优秀架构师的工程师重点投入与持续学习。

引申六:Hexagonal 的性能 trade-off

有人担心 Hexagonal 因为多了 Port 转换层会损失性能。实际测试,我们的订单核心域 P99 延迟从 85ms 降到 72ms,因为分层清晰后能精准定位瓶颈。Mapper 转换确实增加了 1-2ms 开销,但比起代码可读性和可测试性的提升完全可以接受。需要警惕的是过度使用 Mapper:不要在 Domain 内部传递时再做一次 Mapper,只在边界(Adapter ↔ Domain)做一次转换。我们用 MapStruct 在编译期生成 Mapper 代码,运行时几乎零开销。架构选型的核心永远是"业务价值最大化",而非"性能最优",Hexagonal 在大多数业务场景下的性能完全够用,真正的瓶颈通常在数据库和网络。

引申七:架构师的成长路径

这次重构让我深刻认识到架构师不是"画 PPT 的"而是"用代码定义边界的"。优秀架构师必须能写代码、读代码、调试代码,在关键决策点上以代码为锚定。我们团队的架构师每周仍要花 30% 时间写代码,确保对系统的细节有第一手感知。架构师的另一个核心能力是"取舍",任何架构决策都是 trade-off,没有银弹,需要在性能、可维护性、团队能力、上线时间、未来扩展之间反复权衡。最后是"沟通能力",架构师要能在 30 秒内向 CTO 说清楚为什么这么做,要能在 30 分钟内向团队培训如何落地。这三种能力组合是架构师真正的护城河,也是这个职业的最大魅力,值得每一位有志于此的工程师长期投入与不断打磨自己的核心能力。

引申八:架构演进与团队成长的协同

架构不能脱离团队能力存在。团队能力撑不起的"先进架构"反而是负资产。我们这次落地 Hexagonal,先在内部做了 3 次集中培训,每周一次架构演进 review,选 2 位高级工程师做"架构 champion"。重构开始 1 个月内,所有 PR 必须由 architect champion review,确保架构原则被严格遵守。3 个月后,团队中 80% 的工程师能独立写出符合 Hexagonal 原则的代码。架构演进是技术演进和团队演进的双轮驱动,任何只关注技术不关注人的架构师都会失败。培养一个能持续演进的工程师团队,是架构师最大的成就,也是组织级技术能力的真正体现,值得管理者投入长期资源建设健康的工程师成长体系与技术文化。

引申九:Hexagonal 与事件溯源的结合

Hexagonal 架构和事件溯源(Event Sourcing)是天作之合。聚合根产生领域事件,事件作为唯一真相源持久化,状态由事件回放重建。我们订单系统有一个子模块——"订单变更审计",用 ES 改造后,任何订单的状态变化全程可追溯,合规审计和客诉处理效率提升 5 倍。ES 落地的关键是"事件版本管理"和"快照优化",我们用 Axon Framework 实现,事件存储在专门的 event store(EventStoreDB),快照每 50 个事件生成一次。ES 不适合所有业务场景,它对"有强烈审计/可追溯需求"的领域价值巨大,如金融、医疗、合规系统。配合 CQRS 读写分离,ES 能让系统兼具"写端清晰可追溯"和"读端高性能",是 DDD 战术设计的终极形态,值得复杂业务系统的架构师深度研究并掌握。

引申十:Hexagonal 与微前端的对称性

Hexagonal 思想不只适用于后端,前端架构同样需要这种"核心和边界分离"。微前端架构本质上就是前端的 Hexagonal——业务核心和 UI 框架解耦。我们公司一个核心交易页面,业务逻辑用纯 TypeScript 写,只依赖 RxJS;UI 部分用 React 渲染,通过 Ports 接口和业务核心交互。这样,React 升级到 18、19 都不影响业务逻辑,甚至换到 Vue/Svelte 都只换 UI Adapter。前端 Hexagonal 在 SaaS 多端复用场景(Web/iOS/Android/小程序共用业务核心)价值巨大。前后端的架构思想本质上是统一的,都是"业务核心要稳定,边界适配要灵活",这是工程师跨端开发的核心方法论,值得全栈工程师深度理解与应用到自己的项目里。

引申十一:Modular Monolith vs 微服务的再思考

2026 年的架构界出现了"微服务回潮"——一些公司从微服务退回模块化单体(Modular Monolith)。Hexagonal 是模块化单体的核心实现方式:一个进程内多个 Bounded Context,每个 Context 是独立 Hexagonal 模块,模块间通过领域事件或显式接口通信。Shopify、GitHub、Stack Overflow 都是模块化单体的典型代表。微服务的"独立部署、独立扩缩容"在大多数公司其实是伪需求,引入的运维复杂度远超收益。模块化单体能享受"清晰边界"的好处,又避免"分布式系统复杂度"的代价。我们公司一个新业务线决定从一开始就用模块化单体起步,等模块成熟、负载明确再拆微服务。这种"先合后分"的策略已经成为 2026 年新建系统的主流路径,值得每个团队在做架构决策时认真考虑模块化单体方案。

引申十二:Platform Engineering 与架构治理

个人靠纪律,团队靠流程,组织靠平台。Hexagonal 在大组织落地的关键是 Platform Engineering——把架构约束做成平台工具。我们公司有一个内部 platform 团队,提供"标准 Hexagonal 项目脚手架",新项目 5 分钟生成,所有目录结构、依赖规则、CI 模板一键就位。ArchUnit/Konsist 在 CI 强制检查"Domain 不能依赖 Spring",违反直接 block 合并。Backstage 内部开发门户展示每个服务的架构健康度评分,定期 review。这种"平台化的架构治理"让 Hexagonal 在 100+ 工程师团队中也能稳定落地。Platform Engineering 是 2026 年 DevOps 演进的新阶段,值得每个有志于"组织级技术领导力"的工程师深度研究并积极参与建设,这是大规模工程团队真正能持续输出高质量软件的关键基础设施。

总结

这次 6 个月 Hexagonal 架构重构,我们把 8 年的遗留 monolith 从"难以维护的胶水球"变成"清晰分层的工程典范"。核心域代码占比从 12% 提到 62%,单测覆盖率从 23% 提到 78%,生产事故从每月 5 起降到 1 起,新功能开发周期从 6 周缩到 2 周。这些数字背后,是对"业务核心"和"基础设施"清晰分离的工程信念。

更重要的是,我们建立了一套"业务驱动的架构演进方法论":不为重构而重构,任何架构决策都要回答"解决什么业务问题"。Hexagonal 不是银弹,但它提供了一种"把变化挡在边界外"的思维方式,让系统能持续吸收业务变化而不腐化。希望这次复盘能让所有面对遗留系统的工程师少走弯路,真正理解"架构是为业务服务的",这是软件工程最朴素也最深刻的真理。架构师的终极目标不是"写出漂亮的代码",而是"让业务能持续快速演进",这才是技术领导力的真正体现,也是软件工程师在 AI 时代依然不可替代的核心价值所在,值得每一位走在架构师路上的工程师终身追求与精进。架构是一门关于"边界"的艺术,边界划得清,系统就有生命力,边界划得乱,再多代码也是技术债。优秀工程师和普通工程师的核心差距,常常就在能否敏锐地识别和划定这些边界,这种判断力的形成,需要经年累月在真实复杂业务中反复磨砺,没有捷径可走。

最后想说,我们这次重构的最大收获不是技术本身,而是"架构思维"。任何复杂系统都能拆成"核心 + 边界 + 适配",这种思维不只适用于代码,也适用于团队组织、产品规划、个人成长。一个优秀的架构师同时也是优秀的组织设计师、产品策略师、人生规划师,因为底层方法论是相通的。Hexagonal 给了我们一把刻在骨子里的"边界尺",从此看任何系统都能本能地找到"核心在哪、边界在哪、适配如何做"。这是 6 个月重构最珍贵的副产品,也是这门工程艺术真正的魅力所在,值得每位有追求的工程师反复体会与践行,在自己的每一次架构决策中持续磨砺,逐渐沉淀出属于自己的工程世界观与方法论,最终在面对任何复杂业务系统时都能保持清晰的判断力和坚定的工程信念,这是软件工程领域最值得追求的境界,也是无数前辈工程师用一辈子时间打磨出来的真正核心竞争力,值得我们后辈继续沿着这条路坚定地走下去,让软件世界因为这些边界与思考而变得更优雅。

—— 别看了 · 2026