洋葱架构Onion

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

领域为王：芯决定汤的味道

洋葱最贵重的永远是芯。一颗洋葱，剥掉干皮、掰开外瓣，真正决定气味层次的是中心那片嫩芯。厨师的刀法、火候、高汤，全在围着这颗芯转。软件系统也一样，业务规则就是那颗芯——订单算价的规则、风控拦截的条件、推荐排序的权重，它们构成了系统存在的理由。在洋葱架构里，最内层的领域模型就是这颗芯，它由实体、值对象、聚合、领域服务以及仓储接口共同组成。

为什么只能由“芯”来定义规则，而不是数据库？因为规则是业务的语言，是 AI 模型要表达的目标，而数据库只是储存规则的仓库。你换一种数据库，业务规则不该改动一个字。洋葱架构把领域模型放在圆心，同时立下一条铁律：任何外层代码都不得反向依赖领域层，领域层不 import 任何框架、任何 ORM、任何中间件 SDK。这样，系统的“味道”就只由芯决定。

如果用一句话概括依赖方向，可以写成：

切洋葱时，你的刀从外往里走，越靠近芯越小心。架构上也是一样，每一次改动都应从外向里谨慎推进，刀锋永远对向基础设施层，而不是核心。保住芯，汤的味道就稳了。

层级划分：一圈一圈包起来

主厨处理洋葱时，会先把干皮撕掉，再去除外层老瓣，剩下最嫩的部分才入锅。每一层都有自己的角色：外皮负责保护，内瓣负责提供风味。洋葱架构也是按职责一层层包起来的，典型的四层划分从外到内依次是：基础设施层、应用服务层、领域服务层、领域模型。

最外层的基础设施层装着数据库访问、消息队列、邮件发送、第三方 SDK，这些都是“可替换的皮”。紧贴它的应用服务层编排用户请求、管理事务边界，相当于后厨的调度台。再往里的领域服务层处理跨实体的业务规则，比如“下单时同时校验库存与风控”。最内层的领域模型则是纯粹的业务对象，不夹杂任何技术噪音。每一层只掌握自己该知道的，外圈不知道内圈的实现，内圈也看不见外圈的存在。

这四层的关系可以用一个依赖链表达：

现实中，让应用服务层看不到 MySQL 的存在并不难：你只需要定义仓储接口放在领域层，把实现丢在外面。剥开第一层皮，里面永远是一个更干净的内瓣；剥到中心，就是你不想再动的梦幻配方。

依赖反转：让供应商来适应你

主厨不会因为某家食材供应商送不来小洋葱，就改写自己的秘方。他会反过来规定：我要的洋葱必须是紫皮、直径 8 厘米、水分低于 15%，你们谁能供应我就跟谁合作。在洋葱架构里，这条“主厨标准”就是抽象接口。依赖倒置原则说的是：高层业务模块不该依赖低层技术实现，两者都应该依赖抽象，而抽象由领域层自己定义。

想象一个订单系统：应用服务不需要认识“MySQLOrderRepository“或”MongoOrderRepository“，它只需要认识领域层的 OrderRepository 接口。至于这个接口是用 MySQL 实现还是用内存列表实现，由最外层的组装者决定。这种”决定权在外部、标准在内部”的协作方式，就是依赖注入容器存在的意义——在应用启动时，把具体的实现用胶水组装进接口。

形式化地表达依赖倒置，就是两个模块同时面向抽象：

这样一套组合下来，主厨永远掌握“我要什么”的权力，供应商只负责“怎么满足”。以后就算把 MySQL 换成 PostgreSQL，业务层代码一行都不用改——供应商换了，配方没变。

对比三层：汉堡与洋葱的差别

传统三层架构像一只汉堡：展示层、业务层、数据层从上到下叠成一座塔。好吃吗？好吃。但中层肉饼一旦位移，整只汉堡就散了。数据层一旦更换数据库，依赖它的业务层就要跟着改，连展示层都可能被波及。分层确实存在，但方向是“上层依赖下层”，数据像地基一样压在最下面，业务逻辑被地基的形状绑架了。

洋葱架构则完全不同。它不是三片面包垂直叠加，而是一圈一圈水平包裹。业务核心在中心，数据库、UI、外部服务都在外围。对比两种结构，最本质的差异在于耦合对象：三层架构说“UI 驱动一切”，数据表结构决定业务代码；洋葱架构说“领域驱动一切”，业务规则决定外围长什么样。前者的数据流是从外向内直插到底，后者的依赖则是每一圈只认更内圈。

用耦合度来量化两种架构对核心的影响：

汉堡好吃但怕塌，洋葱耐存放且能一层层剥开。遇到业务演进时，三层架构常常要重写肉饼；洋葱架构只需要把新需求翻译成内层的规则，再在外层补一个新端口。架构的灵活性，就藏在这种“芯稳皮可变”的结构里。

可测性：先尝芯，再上菜

一道好汤出锅前，主厨会用小勺单独尝一口汤芯，确认咸淡后才会注入容器端给客人。他不会等到整锅端上桌、客人动勺了才发现问题——那太晚了。洋葱架构最大的红利，就是你不需要启动数据库、不需要拉起消息队列，就可以直接品尝业务逻辑。因为领域层是纯的，它不依赖任何基础设施，测试时可以像操作普通函数一样验证规则。

这就带来一个关键的实践：外围依赖全部替换成 Mock 替身。测试订单算价时，不用真的连 MySQL，而是注入一个“内存版仓储”。被测系统只认 OrderRepository 接口，根本不在乎背后是数据库还是字典。单元测试因此变得飞快，几百条用例跑完只要几十毫秒，开发者可以每改一行代码立刻跑一遍，形成秒级反馈循环。

这种替换的合法性可以用等价式描述：

正因为这种等价性，测试金字塔才能落地：底层是大量廉价快速的单元测试，顶层是少量昂贵缓慢的集成测试。主厨先尝芯，确认味道再上桌；开发者先单测核心，再谈环境搭建。汤的稳定，是靠每一次小抿尝出来的。

DDD配合：一整个洋葱由小鳞瓣构成

一整颗洋葱剥开后，你会发现它不是一个密实的球，而是由许多小鳞瓣层层环抱组成的。每个鳞瓣都有自己的薄皮、自己的汁液，凑在一起才是完整的风味。领域驱动设计（DDD）中的限界上下文就像这些鳞瓣：订单上下文、支付上下文、库存上下文，各自是独立的小洋葱，内部构建自己的领域模型和语言，彼此之间通过明确接口协作。

在洋葱架构里实现 DDD，最关键的是把聚合根放进领域模型的圆心。聚合根是保证一致性的边界，比如“订单”这个聚合负责维护订单项的不变量，任何对订单项的修改都必须穿过它。同时，仓储接口也归领域层所有，它表达的是“我需要一个能存订单的地方”，至于存到哪里，交给外层实现。这种安排让领域事件的发布也变得干净——事件在领域模型中产生，由应用服务转发给消息队列，事件的“语义”与“传输”就此解耦。

多个限界上下文之间，要遵守一条拓扑约束：

一个大型系统，就是由这些互相独立又协同的鳞瓣组成的洋葱球。每一瓣都有自己严密的芯，瓣与瓣之间通过防腐层交换信息。只有当每颗小洋葱都靠领域规则而不是数据库结构来定义时，整个系统才会像一颗真正的洋葱那样，层层分明、久放不坏。

AI 应用场景

Python 演示

# 洋葱架构极简演示:订单折扣计算# 领域层:定义实体/值对象/仓储接口from abc import ABC, abstractmethodfrom dataclasses import dataclass, field  @dataclassclass LineItem:    sku: str    price: float    qty: int  @dataclassclass Order:    id: str    items: list = field(default_factory=list)     def total(self) -> float:        return sum(i.price * i.qty for i in self.items)  class OrderRepository(ABC):    @abstractmethod    def save(self, order: Order) -> None: ...     @abstractmethod    def find(self, order_id: str) -> Order: ...  class PricingService:    # 领域服务:只关心业务规则,不认识数据库    def apply_discount(self, order: Order, rate: float) -> float:        raw = order.total()        return round(raw * rate, 2)  # 应用层:编排用例,管理事务边界class OrderAppService:    def __init__(self, repo: OrderRepository, pricing: PricingService):        self._repo = repo        self._pricing = pricing     def checkout(self, order: Order, discount_rate: float) -> float:        final = self._pricing.apply_discount(order, discount_rate)        self._repo.save(order)        return final  # 基础设施层:实现接口,放在最外层class MemoryOrderRepository(OrderRepository):    def __init__(self):        self._db = {}     def save(self, order: Order) -> None:        self._db[order.id] = order     def find(self, order_id: str) -> Order:        return self._db[order_id]  if __name__ == "__main__":    repo = MemoryOrderRepository()    pricing = PricingService()    service = OrderAppService(repo, pricing)    order = Order("A001", [LineItem("KEYB", 99.0, 2), LineItem("MOUSE", 45.0, 1)])    print("Final total:", service.checkout(order, 0.8))

1. class OrderRepository(ABC)接口定义在领域层，规定“我能存订单”这个能力，具体实现留待外层给出。
2. class PricingService领域服务是纯业务逻辑，不 import 任何存储或框架，可以原封不动地放进单元测试。
3. class OrderAppService应用服务只编排检查和保存流程，自身不知道 MySQL 或 Redis 的存在。
4. class MemoryOrderRepository(OrderRepository)基础设施层作为最外层实现接口，将来换数据库只需新增一个类。
5. service = OrderAppService(repo, pricing)在入口处完成依赖注入，把具体实现装配进抽象接口，这就是洋葱的“组装点”。

常见误区

面试题