这是一篇关于**场景题、系统边界与“那个面试官自己也圆不回来的方案”** 的技术文章。

在软件的浩瀚星河里，架构师是那个绘制星图的人。然而，最精美的星图，也常常在现实的引力面前扭曲、破碎。本文将通过一个虚构但极具代表性的**系统设计面试场景**，深入探讨系统边界的定义、架构决策的取舍，以及一个看似完美却最终被面试官自己推翻的方案背后，所隐藏的关于**康威定律**、**领域驱动设计**和**技术债务**的深刻教训。

全文约 12000 字，包含大量代码示例和架构图。

# 场景题、系统边界与那个面试官自己也圆不回来的方案

## 序章：完美的简历与完美的开始

下午两点，深圳南山某栋写字楼的会议室里，空调嘶嘶地吐着冷气。张工（化名）面前坐着一位头发略显稀疏的面试官，看起来不过三十五岁上下，眼神里透着资深技术人特有的审视。

这是一家准独角兽公司的架构师岗位面试。张工刚刚结束前两轮的技术面，这是最终的 **“架构定级面”**。

“我看你简历上写，你们之前做了一个支撑日活百万的电商中台？”面试官翻着简历，语气平淡地问。

“是的，我主要负责订单中心和库存系统的解耦。”张工答得很稳。

“好，那我们别绕圈子了，直接来个**场景题**。”面试官合上简历，身体前倾，在白板上画起了图，“假设我们现在要做一个**全球实时物流追踪平台**。类似于把你挂在京东、淘宝上的订单物流信息聚合起来，给C端用户提供‘一站式’查询。你作为架构师，怎么设计它的**系统边界**？”

张工点了点头，心中快速地盘算着：全球、实时、聚合——这题的坑不少。

“我先明确一下需求边界。”张工站起身，走到白板前，拿起笔，“第一，数据来源是各个异构的快递公司接口，有SOAP的，有REST的，甚至可能有FTP文件。第二，用户查询是读多写少，但要求高实时性。第三，我们只做聚合和展示，不做物流业务本身的变更。”

面试官点头，示意他继续。

张工画下第一个圈：
```plaintext
+---------------------+       +---------------------+
|                     |       |                     |
|   客户端 (APP/Web)   |       |   快递公司API网关    |
|                     |       |   (顺丰/通达/京东)  |
+---------------------+       +---------------------+
          ^                               ^
          |                               |
          v                               v
+---------------------+       +---------------------+
|                     |       |                     |
|     ??? 我们的系统在哪？    |       |    (外部复杂异构)  |
|                     |       |                     |
+---------------------+       +---------------------+
```

“边界问题，是架构设计的原罪。”张工在中间画了一个大椭圆，“我们必须在这里建立一个**防腐层（Anti-Corruption Layer）**。”

## 第一章：边界即政治——系统边界的定义与代价

在开始拆解这个面试题之前，我们必须先达成一个共识：**系统边界不仅仅是技术问题，更是一个政治问题和成本问题** 。

### 1.1 什么是系统边界？
在软件架构中，边界是将一个系统与另一个系统，或将系统内部高内聚模块与低耦合模块分隔开来的**逻辑或物理线** 。它定义了“什么是我做的”和“什么是别人做的”。

在《架构整洁之道》中，边界的形式多种多样：从最基本的源代码级别的依赖隔离（如Maven模块），到部署级别的动态链接库，再到进程级别的本地进程通信，最后到最强大的服务级别（微服务）的边界 。

对于我们的物流追踪平台，边界至少有三层：
1.  **与外部快递公司的边界**：如何防止外部系统的“脏数据”和“不稳定协议”污染我们的核心域？
2.  **内部业务模块的边界**：物流追踪是应该跟用户积分、推送通知放在一个库里，还是分开？
3.  **技术与业务的边界**：缓存是边界吗？消息队列是边界吗？

面试官看着张工画出的防腐层，嘴角露出一丝不易察觉的微笑。这在他的预期之内。但他真正想听的，是接下来关于“如何防腐”的细节。

### 1.2 边界定义不清的代价
为什么很多项目最后变成了“大泥球”？因为边界模糊 。
想象一下，如果我们的物流系统没有明确的边界：
- 顺丰的接口突然增加了一个签名参数，因为我们的代码里到处散落着直接调用顺丰硬编码的代码，导致全站崩溃。
- 快递员的状态字段“已签收”在圆通叫`status=3`，在中通叫`delivered=true`，业务逻辑层为了适配，写满了if-else，最终代码腐化。

**系统边界是我们用来对抗混乱的唯一武器** 。

张工开始在白板上细化他的方案。他要构建一个坚不可摧的“堡垒”。

## 第二章：那个“完美”的方案——面试官的得意之作

张工画下了一个典型的六边形架构（端口与适配器模式）的变体。他不仅考虑了技术，还考虑了团队协作——即**康威定律**的影响 。

### 2.1 宏观架构：BFF与防腐层

由于前端有多种（APP、小程序、H5），且每种前端对数据的要求不同（APP要更详细的轨迹点，H5只要简略信息），张工引入了**BFF层（Backend For Frontend）** 。

```plaintext
                        物流追踪平台架构图

    [客户端层]
    APP            H5             小程序
    |              |               |
    +--------------+---------------+
                   |
    [边界：协议转换]
    v              v               v
+---------------------------------------------------------------------------+
|  BFF层 (体验适配)                                                            |
|  (GraphQL/REST) - 根据客户端组装数据、字段裁剪、合并请求                            |
+---------------------------------------------------------------------------+
                   |
    [边界：业务与数据聚合]
                   v
+---------------------------------------------------------------------------+
|  核心业务层 (物流域)                                                          |
|  - 追踪号解析服务                                                            |
|  - 轨迹聚合服务                                                              |
|  - 订阅/推送管理                                                             |
+---------------------------------------------------------------------------+
                   |
    [边界：防腐]
                   v
+---------------------------------------------------------------------------+
|  防腐层 (Anti-Corruption Layer)                                           |
|  - 顺丰适配器 (SF-Adapter)   - 通达系适配器 (TDT-Adapter)                   |
|  - 统一物流领域模型 (TrackingVO)                                            |
|  - 异常隔离舱 (熔断/重试)                                                     |
+---------------------------------------------------------------------------+
                   |
    [边界：外部系统]
                   v
    (SOAP)         (HTTP)         (FTP)
      顺丰接口       圆通接口        京东接口
```

张工指着白板解释道：
“这是一个标准的**分层架构加上六边形架构**的混合体。”
1.  **BFF层**：负责处理前端的非功能性需求。比如APP需要实时刷新，BFF可以跟后端保持长连接，然后对APP只做REST。这一层由前端团队维护，遵循康威定律——谁用谁维护 。
2.  **核心业务层**：这是我们系统的“灵魂”。它不依赖任何外部具体实现。它定义了一个纯净的“物流域模型”，比如`TrackingNumber`、`LogisticsEvent`。它只关心业务规则，比如“一个包裹如果超过15天无更新，标记为异常”。
3.  **防腐层**：这是抵御外部混乱的“城墙”。每个快递公司都有一个专属的适配器。适配器的工作是：将外部恶心的数据结构，转换成我们核心层能理解的美丽的领域模型。

### 2.2 代码实现：防腐层的艺术

为了展示自己的实力，张工在白板上写下了关键的接口定义。

**第一步：定义核心领域模型（在核心业务层）**
这是我们的“净土”，不能被污染。
```java
// 核心领域包：com.logistics.core.domain
public class TrackingInfo {
    private TrackingNumber trackingNumber;  // 值对象
    private LogisticsCompany company;        // 枚举
    private List<TrackingEvent> events;      // 标准化的轨迹事件
    private DeliveryStatus status;            // 标准状态：PENDING, IN_TRANSIT, DELIVERED, EXCEPTION
    private ZonedDateTime lastUpdated;

    // 业务规则方法
    public boolean isDelayed() {
        // 核心逻辑：如果超过预期时间且状态不是已签收
        return status == DeliveryStatus.IN_TRANSIT && 
               lastUpdated.isBefore(ZonedDateTime.now().minusDays(3));
    }
}

public class TrackingEvent {
    private String eventCode;      // 标准事件码：如 1001-已揽收
    private String description;    // 标准描述
    private GeoPoint location;     // 经纬度
    private ZonedDateTime timestamp;
}
```

**第二步：定义防腐层的输出端口（在核心业务层）**
这是核心层要求的“接口”，由外部适配器实现。依赖关系指向核心层 。
```java
// 核心领域包：com.logistics.core.spi
public interface LogisticsFetcher {
    /**
     * 根据快递公司和单号获取标准化的物流信息
     * 这是防腐层必须实现的契约
     */
    Optional<TrackingInfo> fetch(String trackingNumber, LogisticsCompany company);
}
```

**第三步：实现具体的适配器（在防腐层/基础设施包）**
这是与“魔鬼”打交道的地方。
```java
// 防腐层包：com.logistics.infrastructure.adapter.sf
public class ShunfengFetcher implements LogisticsFetcher {

    @Override
    public Optional<TrackingInfo> fetch(String trackingNumber, LogisticsCompany company) {
        // 1. 调用顺丰的SOAP接口 (使用静态工厂创建客户端)
        SFSoapClient client = new SFSoapClient();
        SFResponse response = client.queryRoute(trackingNumber);

        // 2. 丑陋的数据转换 - 这就是防腐的核心工作
        if (response == null || response.isError()) {
            // 触发熔断或降级
            return Optional.empty();
        }

        // 3. 构建标准化的领域模型
        TrackingInfo info = new TrackingInfo();
        info.setTrackingNumber(TrackingNumber.of(trackingNumber));
        info.setCompany(company);

        // 顺丰的状态码 1-已揽收, 2-运输中, 3-派送中, 4-已签收 -> 映射到标准状态
        DeliveryStatus standardStatus = mapStatus(response.getStatusCode());
        info.setStatus(standardStatus);

        List<TrackingEvent> events = response.getRoutePoints().stream()
            .map(point -> {
                TrackingEvent event = new TrackingEvent();
                event.setEventCode(point.getOpCode()); // 可能需要一个映射表
                event.setDescription(point.getDesc());
                // 顺丰给的是文本地址，需要调用GIS服务转成经纬度？这里先留空
                event.setLocation(GeoPoint.unknown());
                event.setTimestamp(point.getTime());
                return event;
            }).collect(Collectors.toList());
        info.setEvents(events);

        return Optional.of(info);
    }

    private DeliveryStatus mapStatus(String sfCode) {
        // 这就是边界处的逻辑
        switch(sfCode) {
            case "1": return DeliveryStatus.PENDING;
            case "2": return DeliveryStatus.IN_TRANSIT;
            case "4": return DeliveryStatus.DELIVERED;
            default: return DeliveryStatus.EXCEPTION;
        }
    }
}
```

### 2.3 数据流动与存储

“那数据怎么存？”面试官问。
“CQRS模式。”张工脱口而出。
“查询和更新分离。对于物流这种场景，用户99%的操作是查询。我们不需要把轨迹的每一次变化都实时写入关系型数据库，那会死锁的。”

张工画出了数据流图：
```plaintext
写入流 (顺丰回调/轮询拉取):
[防腐层] -> 产生领域事件(TrackingUpdated) -> [消息队列] -> [事件处理器] -> [时序数据库] (存储轨迹序列)
                                                               -> [Redis] (存储最新状态/热点数据)

读取流 (用户查询):
[用户请求] -> [BFF] -> [查询网关] -> [Redis Cache] (如果命中直接返回)
                              -> [时序数据库] (查询历史轨迹)
```

“这就是我的方案。”张工放下笔，胸有成竹。

## 第三章：崩塌——那个圆不回来的致命追问

会议室安静了五秒钟。面试官盯着白板上的图，目光在“防腐层”和“核心业务层”之间来回游移。

“很好。”面试官终于开口，“考虑得很全面，DDD（领域驱动设计），BFF，CQRS，微服务，都用上了。这是一个教科书级别的方案。”

张工刚想谦虚两句，面试官话锋一转：
**“但是，如果我告诉你，我们公司现在只有5个后端开发，物流追踪只是我们公司大后台里的一个模块，下个月就要上线。你画这个方案，打算写多少行代码？”**

张工一愣。这确实是一个现实问题。

“我们可以……分阶段迭代……”张工试图补救。

“好，那我们就聚焦这个**防腐层**。”面试官站了起来，开始在这个“完美方案”上挑刺。

### 追问一：领域模型的“统一”成本

“你定义了一个叫`TrackingEvent`的领域对象，里面有标准事件码、标准描述、标准经纬度。”面试官指着代码，“我问你，如果中通的轨迹里，根本没有经纬度，只有‘已发往北京分拨中心’这样的文本，你的`GeoPoint location`填什么？填`unknown`？”

“填默认值。”张工说。

“那好，一个月后，产品经理要求在地图上画轨迹。你的`unknown`怎么画？是不是要从那段文本里用正则表达式解析地址，再用GIS服务转成经纬度？这个逻辑写在哪儿？写在适配器里，还是写在核心层？”

空气凝固了。这是一个典型的 **“边界泄漏”** 场景。
- 写在适配器里：适配器承担了本不该属于它的“解析”业务逻辑，变得臃肿。
- 写在核心层：核心层引入了对“字符串解析”的关注，破坏了纯洁性。

**核心层看似“统一”的模型，为了兼容所有快递公司的特殊性，最终要么退化成`Map<String, Object>`，要么充斥着大量的`if(company == SF)`的特殊判断。当特殊判断遍布核心层时，所谓的边界就不复存在了。** 这是一个“完美的模型”在残酷现实面前的妥协。

### 追问二：谁为“通用”买单？

“你定义了`LogisticsFetcher`这个SPI接口。”面试官继续说，“顺丰的接口是实时SOAP，响应时间200ms。百世快递没有实时接口，只有每天凌晨同步的FTP文件，你怎么`fetch`？是去读离线仓库吗？”

张工沉默了。他的接口定义是`Optional<TrackingInfo> fetch(String number)`，这隐含了一个假设：所有快递公司都支持**实时查询**。但现实是，很多小快递公司只支持“回调推送”或者“离线文件”。

- 对于只支持推送的公司，`fetch`方法根本无法实现。为了适配这个接口，是不是要在适配器里维护一个本地的“最近更新缓存”？那这个缓存的一致性怎么保证？

### 追问三：那个最致命的“圈不回来”

面试官拿起红笔，在“防腐层”和“快递公司”之间画了一个大大的问号。

“你画了一个完美的**依赖倒置**——核心层定义接口，适配器实现接口。这没错。但是，我问你一个网络问题：**当顺丰的接口因为光缆被挖断，彻底挂掉的时候，你的`ShunfengFetcher.fetch`方法会抛出连接超时异常。这个异常，你是怎么处理的？你的防腐层承诺的‘隔离’，能阻止这个异常崩溃你的核心业务层吗？**”

张工说：“我们会捕获异常，返回`Optional.empty()`。核心层如果收到`empty`，就知道没查到数据。”

“那好，用户查一个顺丰的单号，顺丰挂了，你返回`empty`。那用户看到的是什么？‘查无此单’？但用户的包裹明明在路上！这时候客服电话会被打爆。你的核心层因为收到了`empty`，会把一个在途的包裹标记为‘不存在’吗？”

**核心层的逻辑是基于“有”或“无”的二元结果。但外部系统的失败，是一种“薛定谔的猫”——你不知道它是真的没有这个单，还是只是暂时查不到。** 防腐层如果只是简单地吞掉异常返回空，实际上是把外部系统的“可用性故障”转换成了业务上的“数据错误”。这种错误，比系统崩溃更可怕，因为它会产生脏数据。

面试官说：“你设计的防腐层，只防腐了数据结构，没防腐‘可用性’。你要区分‘查不到’和‘查不出’。为了做到这一点，你是不是需要把‘超时’、‘熔断’这种基础设施概念，也作为业务状态的一部分传递给核心层？那你的核心层还能纯粹吗？你是不是得在`TrackingInfo`里加一个`isFetchTimedOut`的字段？”

张工彻底愣住了。他发现，如果要把这个“完美的理论方案”落地，他必须在**纯洁性**和**现实性**之间做出痛苦的妥协。而一旦妥协，那个精心构建的边界就会布满窟窿。

## 第四章：深度剖析——为什么“完美方案”会崩塌？

这场面试的结果不言而喻。张工的方案在理论上无懈可击，但在面试官一连串的现实拷问下，暴露了架构设计中一个永恒的困境：**我们无法构建一个既纯粹又完美的边界。**

让我们来深度复盘一下，这个方案到底“死”在了哪里。

### 4.1 理论困境：现实世界不存在“完美适配”

张工设计的防腐层，本质上是一个**翻译层** 。它试图把源系统（快递公司）的语言翻译成目标系统（核心域）的语言。

但翻译本身是有损失的。当一个概念在源语言中不存在时（比如小快递公司没有经纬度），翻译者（适配器）只能“发明”或者“省略”。这种人为的“统一”掩盖了业务的复杂性，导致核心层基于错误的前提做出业务判断。

**真正的边界，不是抹平差异，而是管理差异。** 有时候，承认差异的存在（比如将数据源分为“实时型”和“离线型”两种接入模型），比强行统一更健壮。

### 4.2 技术债务：YAGNI 与 Big Design Up Front

《架构整洁之道》中提到了一个核心矛盾：**YAGNI（你不会需要它）和过度设计的权衡** 。
张工的设计，是为一个假设的未来（所有快递公司都提供实时经纬度）设计的。他为了未来可能出现的“地图轨迹”功能，提前在核心模型中加入了`GeoPoint`字段。

这就是典型的 **“过度设计”**。它带来了三个坏处：
1.  **复杂性增加**：为了填充一个可能永远用不上的字段，适配器代码变得复杂。
2.  **误导性**：给前端传递了一个`GeoPoint.unknown`的信号，前端同学可能会困惑。
3.  **僵化性**：如果以后真的需要经纬度，可能发现当初设计的`GeoPoint`结构根本满足不了需求（比如精度不够），但因为这个字段已经上线，修改成本极高。

**架构师需要有一种“未卜先知”的能力，但这种能力不是体现在堆砌功能上，而是体现在保留“可塑性”上** 。在这个案例里，更合理的做法是：核心模型只包含所有快递公司**当前都具备**的共性（如单号、状态、时间、文本描述），至于经纬度，作为可扩展的`Map<String, Object>`属性传递，或者干脆等有了明确需求再加。

### 4.3 康威定律与团队阵型

别忘了，面试官说“公司只有5个人”。
5个人的团队，维护一个这样的“多核”系统（BFF、Core、Adapter、MQ、时序DB），光服务部署的YAML文件就能写到手软。

张工的设计遵循了微服务的逻辑边界，但忽略了**团队边界** 。康威定律告诉我们：系统的架构会复制生产它的组织的沟通结构。
- **现状（5个人）**：适合单体分层架构，或者简单的“大服务+模块化”。
- **设计（多服务分布式）**：适合“前端团队+BFF团队+后端核心团队+数据团队”的配置。

用5个人的团队去支撑一个需要20个人维护的架构，结果是：每个人都要关注整个调用链，没有人能精通所有环节。系统边界不仅没有带来“隔离”，反而因为网络调用增加了沟通成本和故障排查难度。

### 4.4 可用性与业务连续性的边界

最致命的那个“超时”问题，触及了架构设计的灵魂：**故障总是会发生**。
在分布式系统中，我们不能假设外部依赖永远可用。但业务方（用户）也不接受“查无此单”的答复。

**真正成熟的架构，会在核心业务逻辑之外，专门设计一套“降级”和“容错”的边界逻辑。** 这套逻辑不属于核心业务，但它是系统的“安全带”。

在这个案例中，一个“兜底”的方案可能是：
1.  对于查不到的单号，不直接返回“空”，而是返回一个“查询中”的状态，并异步重试。
2.  核心业务层需要理解“未知”状态。
3.  前端UI需要展示“网络开小差，稍后再试”而不是“单号不存在”。

但这就意味着，**“网络不可用”这个技术概念，最终侵入了业务模型，成为了业务状态的一部分。** 这也许是架构师为了系统生存不得不付出的代价。

## 第五章：重构——接受不完美的“实用主义架构”

假设你是这位面试官，或者说，我们现在就是那5个人的团队，面对这个物流追踪需求，该如何设计一个**实用主义**的、能快速上线、又能为未来保留扩展性的架构？

我们不再追求理论上的绝对纯洁，而是追求**解决当前主要矛盾的优雅**。

### 5.1 重新审视边界：粗粒度 + 防御式编程

既然人少，我们就不能拆分微服务。一个 Spring Boot 应用就够了。但我们仍然需要逻辑边界。

**第一步：合并BFF与核心层**
暂时不要单独的BFF层。直接在Web层（Controller）处理简单的视图组装。这不是长远之计，但对于初期迭代，少一个服务就少一份运维压力。

**第二步：重新设计防腐层——引入“服务网关”模式**
我们不搞复杂的SPI和多适配器，而是在同一个服务内，创建一个`LogisticsGateway`门面。这个门面对内提供接口，内部封装了所有的“脏活”。

```java
@Service
public class LogisticsGateway {
    // 注入各种客户端，以及一个“兜底缓存”
    @Autowired
    private ShunfengClient shunfengClient;
    @Autowired
    private YtoClient ytoClient;
    @Autowired
    private OfflineDataCache offlineDataCache; // 用于处理FTP数据源的缓存

    public TrackingResult fetch(String number, String companyCode) {
        // 这是一个非常实用的方法，它知道“如何失败”
        try {
            // 使用“舱壁模式”，不同公司的调用使用不同的线程池或超时设置
            if ("SF".equals(companyCode)) {
                return fetchFromSF(number);
            } else if ("YTO".equals(companyCode)) {
                return fetchFromYTO(number);
            } else {
                return TrackingResult.unsupported("不支持的快递公司");
            }
        } catch (TimeoutException e) {
            // 监控报警
            log.error("Fetch timeout for {}:{}", companyCode, number);
            // 返回一个特殊的“未知”状态，而不是空
            return TrackingResult.unknown("暂时无法查询，请稍后重试", companyCode, number);
        }
    }

    private TrackingResult fetchFromSF(String number) throws TimeoutException {
        // 顺丰实时查询逻辑
        SFResponse resp = shunfengClient.query(number, 1000); // 设置1秒超时
        // 转换...
        return TrackingResult.success(convertedData);
    }

    private TrackingResult fetchFromYTO(String number) {
        // 圆通可能只有离线数据，先去本地缓存查
        Optional<OfflineData> data = offlineDataCache.get("YTO", number);
        if (data.isPresent()) {
            return TrackingResult.success(convertOffline(data.get()));
        } else {
            // 如果离线没有，可能真的是查不到，但也可能是文件还没同步过来
            return TrackingResult.unknown("该单号尚未同步，请明天再试", "YTO", number);
        }
    }
}
```

**核心要点**：
- `TrackingResult`是一个包含**状态码**（SUCCESS, UNKNOWN, UNSUPPORTED, TIMEOUT）的响应对象。它将外部系统的异常显式地作为结果的一部分传递回去。
- 上层（Controller）根据状态码决定返回给用户什么样的文案，以及是否要缓存这个“失败”结果避免重复击穿。
- 这种设计不完美，但它务实。它承认了外部世界的不可靠，并为此留了余地。

### 5.2 数据存储：普通DB就够了

人少、数据量初期不大，别上时序数据库。
- 建一张 MySQL 表 `tracking_record`：`id, company_code, tracking_number, latest_data_json, last_update_time`。
- 再建一张 `tracking_history`：存储每次抓取的原始快照（JSON格式）。
- 查询时，先查缓存，再查MySQL。
- 异步任务轮询或者接收回调，更新这两张表。

### 5.3 代码演化：从具体到抽象

不预先做抽象的接口（`LogisticsFetcher`），而是从具体的实现开始写。先写顺丰的，再写圆通的。当写到第三家快递公司时，如果发现代码大量重复，再考虑提取抽象工具类或模板方法。

**“重构”优于“预构”**。这是应对YAGNI最好的方式 。

## 第六章：结语——架构师的天命与“圆不回来”的智慧

回到那个面试现场。如果张工在最后，不是试图强行“圆回”自己的完美方案，而是坦然承认：“您说得对，这个方案在我们的资源限制下过于超前了。在实际落地中，我会简化核心模型，接受部分数据的不一致性，并专注于设计一个健壮的容错机制，比如我会把‘超时’和‘不支持’作为一等公民纳入返回结果的设计中。”——那么面试结果会不会不同？

“那个面试官自己也圆不回来的方案”，其实并不是面试官真的圆不回来，而是他在用一连串的追问，撕开理论完美的外衣，逼迫应试者直面现实世界的混乱。他想要的，不是一个只会背诵《架构整洁之道》的复读机，而是一个能在混乱中建立秩序，并清楚知道这种秩序会在何处、为何种代价而崩塌的**实战派**。

**系统边界，是我们对这个世界做出的承诺。而边界上的“漏洞”，则是我们为这个世界的不完美预留的慈悲。**

作为架构师，天命不在于建造一座永不陷落的完美城堡，而在于清楚地知道城墙的哪个垛口最容易受到攻击，并在敌人攻破时，依然能有条不紊地组织巷战，保住王宫（核心业务）。

最后，以一句我很喜欢的话作为结尾：
**“所有架构图在遇到生产环境的第一毫秒都是错的。架构师的工作，就是不断地修正这个错误，并且确保在修正的过程中，系统还能正常运转。”**

### 参考文献与推荐阅读
1.  Martin Fowler. 《Patterns of Enterprise Application Architecture》.
2.  Eric Evans. 《Domain-Driven Design: Tackling Complexity in the Heart of Software》. 
3.  Robert C. Martin. 《Clean Architecture: A Craftsman‘s Guide to Software Structure and Design》. 
4.  Sam Newman. 《Building Microservices》.
5.  Microsoft Azure. 使用域分析为微服务建模