使代码库难以维护的结构性问题
误用的模式、反模式和日后会引发问题的架构决策
组件之间了解过多，导致变更到处蔓延
业务逻辑放错层级，UI 逻辑在服务中，数据访问散落各处
适用于小应用但随系统增长而崩溃的模式
架构顾问知道您何时违反了核心设计原则
每个模块应该只有一个变更的理由
违规： 一个同时处理认证、日志和业务逻辑的服务
对扩展开放，对修改关闭
违规： 随着每个功能不断增长的巨型 switch 语句
依赖抽象，而非具体实现
违规： 业务逻辑直接实例化数据库客户端
多个专用接口优于一个通用接口
违规： 强制客户端实现不需要的方法
看看架构顾问如何指导结构改进
// userService.ts
import { orderService } from './orderService'
// orderService.ts
import { userService } from './userService'
// 循环依赖！变更双向蔓延循环依赖：变更影响两个模块
// userService.ts
import { OrderRepository } from './interfaces'
// orderService.ts
import { UserRepository } from './interfaces'
// 都依赖抽象，而非彼此引入接口打破循环
class OrderController {
async createOrder(req, res) {
// 验证
if (!req.body.items) throw new Error('...')
// 业务逻辑
const total = calculateTotal(req.body.items)
const discount = applyDiscount(total, req.user)
// 数据库
await db.orders.create({ ... })
// 邮件
await sendEmail(req.user.email, 'Order confirmed')
}
}控制器处理验证、业务逻辑、数据库和邮件
class OrderController {
async createOrder(req, res) {
const dto = OrderDto.fromRequest(req)
const order = await this.orderService.create(dto)
return OrderResponse.from(order)
}
}
// 业务逻辑在 OrderService
// 邮件在 NotificationService
// 验证在 OrderDto每一层只有单一职责
架构顾问的视野超越单个文件。它理解您的系统如何 组合在一起，并识别影响整个代码库的结构问题。
构建模块之间依赖关系的图谱
检查职责是否在正确的层级
识别设计模式和反模式
映射依赖
构建组件之间关系的图谱
识别模式
识别架构模式及其使用方式
评估耦合
衡量组件之间的紧密程度
建议改进
推荐重构方案和迁移路径
好的架构是无形的。糟糕的架构会拖慢一切。
干净的架构意味着新功能可以顺利集成，无需与代码库作斗争
低耦合意味着变更不会波及整个系统
良好的结构能应对增长而无需重写
今天做出的架构决策会成为明天的约束。
架构顾问帮助您做出明智的决策。