系统架构设计手记：架构不是选型，是划边界

系统架构设计常被误解为画几张部署图、选几个中间件、定几个微服务。其实，架构的核心不是技术堆叠，而是在不确定性中划定边界，让系统在变化中保持可演进。代码只是架构的投影，真正的设计发生在代码之外。

举个简单例子。订单创建后，需要通知库存、支付、物流。最初，很多人会这样写：

orderService.create(order);
inventoryClient.lock(order);
paymentClient.pay(order);
logisticsClient.schedule(order);

它能运行，也足够直观。但问题在于：订单服务变成了所有下游的调度中心。任何下游接口变化、超时策略、重试逻辑，都会污染订单主流程。架构师看到的不只是调用，而是依赖方向：订单不应该依赖具体实现，而应该依赖事件或端口。

于是，架构师会把变化关进边界里。代码可以很少，比如只定义一个事件：

public record OrderCreated(String orderId) {}

订单只发布事件，库存、支付、物流各自订阅。新增下游时，只需新增订阅者，订单服务不必修改。这就是“稳定依赖抽象，变化隔离在边界外”的朴素落地。

但架构师不会因此把所有调用都改成消息队列。如果业务要求强一致、低延迟，同步调用可能更合适。架构设计没有银弹，只有约束下的最优解。一致性、可用性、延迟、成本、团队认知，都是权衡项。CAP、BASE、DDD、微服务、事件驱动，都是工具，不是目标。

架构师还要关注非功能需求：性能、安全、可观测性、可测试性、可部署性。这些往往比功能需求更能决定架构形态。比如，系统需要秒级扩容，无状态服务、配置外置、健康检查就是架构约束；涉及资金，幂等、对账、审计日志就是架构约束。功能决定系统做什么，非功能决定系统能走多远。

架构也不是一个人的蓝图，而是团队的共识。康威定律说，系统设计会映射组织沟通结构。团队按业务能力划分，架构自然倾向领域边界；团队按技术分层，架构就容易变成层层调用。架构师要做的，是把边界讲清楚，写成文档，做成决策记录，让团队知道什么可以改、什么不能碰、为什么这样选。

好的架构，在代码里往往看不见。它不炫耀微服务，不堆砌中间件，而是让每个组件只承担该承担的职责，让每次变化只影响一小块。架构师的价值，不是画更多图，而是让团队少走弯路、敢改、能演进。

真正的好架构，会在下一次流量高峰或业务转型时显现：别人忙着救火，你只需要加一个订阅者、换一个适配器、扩一组无状态节点。