Architecture Patterns
2026-03-30
新闻来源:网淘吧
围观:32
电脑广告
手机广告
架构模式
是什么
用于构建可维护、可测试系统的后端架构模式:整洁架构、六边形架构和领域驱动设计。
何时使用
- 从零开始设计新的后端系统
- 重构单体应用以提高可维护性
- 为团队建立架构标准
- 创建可测试、可模拟的代码库
- 规划微服务拆分
关键词
整洁架构,六边形架构,端口与适配器,DDD,领域驱动设计,分层,实体,用例,仓储,聚合,限界上下文

决策框架:选择哪种模式?
| 适用场景 | 推荐模式 |
|---|---|
| 简单的CRUD应用 | 无需(过度设计) |
| 中等复杂度,团队标准化 | 整洁架构 |
| 外部集成频繁变更的复杂系统 | 六边形架构(端口与适配器) |
| 具有复杂规则和业务领域的场景 | 领域驱动设计 |
| 多团队协作的大型系统 | 领域驱动设计 + 限界上下文 |
快速参考指南
整洁架构分层
┌──────────────────────────────────────┐
│ Frameworks & Drivers (UI, DB) │ ← Outer: Can change
├──────────────────────────────────────┤
│ Interface Adapters │ ← Controllers, Gateways
├──────────────────────────────────────┤
│ Use Cases │ ← Application Logic
├──────────────────────────────────────┤
│ Entities │ ← Core Business Rules
└──────────────────────────────────────┘
依赖规则: 依赖关系仅指向内部。内层绝不导入外层。
六边形架构
┌─────────────┐
┌────│ Adapter │────┐ (REST API)
│ └─────────────┘ │
▼ ▼
┌──────┐ ┌──────────┐
│ Port │◄────────────►│ Domain │
└──────┘ └──────────┘
▲ ▲
│ ┌─────────────┐ │
└────│ Adapter │────┘ (Database)
└─────────────┘
端口: 定义领域所需功能的接口适配器: 可替换的实现(便于测试)
目录结构
app/
├── domain/ # Entities & business rules (innermost)
│ ├── entities/
│ │ └── user.py
│ ├── value_objects/
│ │ └── email.py
│ └── interfaces/ # Ports
│ └── user_repository.py
├── use_cases/ # Application business rules
│ └── create_user.py
├── adapters/ # Interface implementations
│ ├── repositories/
│ │ └── postgres_user_repository.py
│ └── controllers/
│ └── user_controller.py
└── infrastructure/ # Framework & external concerns
├── database.py
└── config.py
模式一:整洁架构
实体(领域层)
from dataclasses import dataclass
from datetime import datetime
@dataclass
class User:
"""Core entity - NO framework dependencies."""
id: str
email: str
name: str
created_at: datetime
is_active: bool = True
def deactivate(self):
"""Business rule in entity."""
self.is_active = False
def can_place_order(self) -> bool:
return self.is_active
端口(接口)
from abc import ABC, abstractmethod
from typing import Optional
class IUserRepository(ABC):
"""Port: defines contract, no implementation."""
@abstractmethod
async def find_by_id(self, user_id: str) -> Optional[User]:
pass
@abstractmethod
async def save(self, user: User) -> User:
pass
用例(应用层)
@dataclass
class CreateUserRequest:
email: str
name: str
@dataclass
class CreateUserResponse:
user: Optional[User]
success: bool
error: Optional[str] = None
class CreateUserUseCase:
"""Use case: orchestrates business logic."""
def __init__(self, user_repository: IUserRepository):
self.user_repository = user_repository # Injected dependency
async def execute(self, request: CreateUserRequest) -> CreateUserResponse:
# Business validation
existing = await self.user_repository.find_by_email(request.email)
if existing:
return CreateUserResponse(user=None, success=False, error="Email exists")
# Create entity
user = User(
id=str(uuid.uuid4()),
email=request.email,
name=request.name,
created_at=datetime.now()
)
saved = await self.user_repository.save(user)
return CreateUserResponse(user=saved, success=True)
适配器(实现层)
class PostgresUserRepository(IUserRepository):
"""Adapter: PostgreSQL implementation of the port."""
def __init__(self, pool: asyncpg.Pool):
self.pool = pool
async def find_by_id(self, user_id: str) -> Optional[User]:
async with self.pool.acquire() as conn:
row = await conn.fetchrow(
"SELECT * FROM users WHERE id = $1", user_id
)
return self._to_entity(row) if row else None
async def save(self, user: User) -> User:
async with self.pool.acquire() as conn:
await conn.execute(
"""INSERT INTO users (id, email, name, created_at, is_active)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (id) DO UPDATE SET email=$2, name=$3, is_active=$5""",
user.id, user.email, user.name, user.created_at, user.is_active
)
return user
模式二:六边形架构(端口与适配器)
当您拥有多个可能发生变化的外部集成时,这是最佳选择。
# Domain Service (Core)
class OrderService:
def __init__(
self,
order_repo: OrderRepositoryPort, # Port
payment: PaymentGatewayPort, # Port
notifications: NotificationPort # Port
):
self.orders = order_repo
self.payments = payment
self.notifications = notifications
async def place_order(self, order: Order) -> OrderResult:
# Pure business logic - no infrastructure details
if not order.is_valid():
return OrderResult(success=False, error="Invalid order")
payment = await self.payments.charge(order.total, order.customer_id)
if not payment.success:
return OrderResult(success=False, error="Payment failed")
order.mark_as_paid()
saved = await self.orders.save(order)
await self.notifications.send(order.customer_email, "Order confirmed")
return OrderResult(success=True, order=saved)
# Adapters (swap these for testing or changing providers)
class StripePaymentAdapter(PaymentGatewayPort):
async def charge(self, amount: Money, customer: str) -> PaymentResult:
# Real Stripe implementation
...
class MockPaymentAdapter(PaymentGatewayPort):
async def charge(self, amount: Money, customer: str) -> PaymentResult:
return PaymentResult(success=True, transaction_id="mock-123")
模式3:领域驱动设计
适用于具有许多规则的复杂业务领域。
值对象(不可变)
@dataclass(frozen=True)
class Email:
"""Value object: validated, immutable."""
value: str
def __post_init__(self):
if "@" not in self.value:
raise ValueError("Invalid email")
@dataclass(frozen=True)
class Money:
amount: int # cents
currency: str
def add(self, other: "Money") -> "Money":
if self.currency != other.currency:
raise ValueError("Currency mismatch")
return Money(self.amount + other.amount, self.currency)
聚合(一致性边界)
class Order:
"""Aggregate root: enforces invariants."""
def __init__(self, id: str, customer: Customer):
self.id = id
self.customer = customer
self.items: List[OrderItem] = []
self.status = OrderStatus.PENDING
self._events: List[DomainEvent] = []
def add_item(self, product: Product, quantity: int):
"""Business logic in aggregate."""
if quantity > product.max_quantity:
raise ValueError(f"Max {product.max_quantity} allowed")
item = OrderItem(product, quantity)
self.items.append(item)
self._events.append(ItemAddedEvent(self.id, item))
def submit(self):
"""State transition with invariant enforcement."""
if not self.items:
raise ValueError("Cannot submit empty order")
if self.status != OrderStatus.PENDING:
raise ValueError("Order already submitted")
self.status = OrderStatus.SUBMITTED
self._events.append(OrderSubmittedEvent(self.id))
仓储模式
class OrderRepository:
"""Persist/retrieve aggregates, publish domain events."""
async def save(self, order: Order):
await self._persist(order)
await self._publish_events(order._events)
order._events.clear()
测试优势
所有模式都支持相同的测试方法:
# Test with mock adapter
async def test_create_user():
mock_repo = MockUserRepository()
use_case = CreateUserUseCase(user_repository=mock_repo)
result = await use_case.execute(CreateUserRequest(
email="test@example.com",
name="Test User"
))
assert result.success
assert result.user.email == "test@example.com"
切勿
- 贫血领域模型:仅有数据而无行为的实体(应将逻辑置于实体内部)
- 框架耦合:业务逻辑中导入Flask、FastAPI、Django ORM等框架组件
- 臃肿控制器:将业务逻辑置于HTTP处理程序中
- 抽象泄露:仓储返回ORM对象而非领域实体
- 跳过层级:控制器直接访问数据库
- 过度设计对简单CRUD应用采用简洁架构
- 循环依赖:用例导入控制器
文章底部电脑广告
手机广告位-内容正文底部


微信扫一扫,打赏作者吧~