架构师成长之路2-设计思想：如何从“写逻辑”升级为“做设计”

最新推荐文章于 2025-09-23 21:34:39 发布

原创最新推荐文章于 2025-09-23 21:34:39 发布 · 892 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#架构

架构师同时被 2 个专栏收录

17 篇文章

订阅专栏

架构师成长之路

11 篇文章

订阅专栏

第2篇｜设计思想：如何从“写逻辑”升级为“做设计”

“你写的是代码，我写的是系统。”
——架构师的自白

很多程序员在职场中，有这样的感受：

“写代码不难，写好代码太难。”
“写功能我没问题，写架构我不敢动。”
“我能把需求做完，但做不出一个优雅的系统。”

如果说第一篇文章我们解决了**“我为什么要成为架构师”的问题，那么这一篇，就是解决“我该如何迈出第一步”**的问题：

这一篇，我们聊聊**“设计思想”**——程序员从写逻辑到做系统设计的第一道鸿沟。

一、程序员初期最容易陷入的误区

我们先看一个真实的初级代码：

public class OrderService {
    public void createOrder(String userId, String itemId) {
        // 1. 校验库存
        int stock = DB.queryStock(itemId);
        if (stock <= 0) {
            throw new RuntimeException("库存不足");
        }

        // 2. 扣库存
        DB.updateStock(itemId, stock - 1);

        // 3. 创建订单
        Order order = new Order(userId, itemId);
        DB.insertOrder(order);

        // 4. 发短信
        SmsUtil.send("下单成功", userId);
    }
}

看起来没毛病，功能齐全。但从设计角度一看，“耦合满天飞”：

数据操作和业务逻辑混在一起；
OrderService 既管库存又管短信；
没有扩展性（比如加上优惠券、日志记录怎么办？）

这就是典型的“写逻辑”思维，只是把流程从 A 做到 B，而不是把模块组织得清晰有序。

二、设计思想是“抽象 + 分层 + 解耦”的系统思维

设计思想不是架空理论，它是让代码更好维护、更易扩展、更能应对变化的“组织之术”。

我们来一一拆解。

✳️ 1. 抽象：从“怎么做”转变为“做什么”

写逻辑的思维是：

“怎么把功能跑通？”

设计的思维是：

“这件事的本质是什么？我能不能把它抽象出来？”

在上面的例子中，我们可以将“库存操作”抽象成一个 InventoryService：

public class InventoryService {
    public boolean hasStock(String itemId) {
        return DB.queryStock(itemId) > 0;
    }

    public void deduct(String itemId) {
        int stock = DB.queryStock(itemId);
        if (stock <= 0) throw new RuntimeException("没货");
        DB.updateStock(itemId, stock - 1);
    }
}

然后 OrderService 就变得清爽了：

public class OrderService {
    private InventoryService inventoryService = new InventoryService();
    private SmsService smsService = new SmsService();

    public void createOrder(String userId, String itemId) {
        inventoryService.deduct(itemId);
        Order order = new Order(userId, itemId);
        DB.insertOrder(order);
        smsService.send(userId, "下单成功");
    }
}

这就是抽象：把“怎么做”封装成方法，对外只暴露“要做什么”。

✳️ 2. 分层：分工合作、各司其职

设计思想第二个核心是**“分层”**，也是架构师最爱画图的一招。

举个三层架构的例子：

层级	职责	类示例
Controller	接收请求、参数校验	`OrderController`
Service	执行业务逻辑	`OrderService`
DAO（Repository）	访问数据库	`OrderRepository`

不分层的代码是“炒一锅乱炖”，你一口下去啥都有；
分层后的代码是“分餐式小火锅”，牛肉、蘑菇、丸子各有容器。

示例：

// Controller 层
@PostMapping("/order")
public ResponseEntity<?> createOrder(@RequestBody OrderDTO dto) {
    orderService.createOrder(dto.getUserId(), dto.getItemId());
    return ResponseEntity.ok("下单成功");
}

// Service 层
public void createOrder(String userId, String itemId) {
    if (!inventoryService.hasStock(itemId)) {
        throw new RuntimeException("库存不足");
    }
    orderRepository.insert(new Order(userId, itemId));
}

// DAO 层
public void insert(Order order) {
    // jdbcTemplate 或 ORM 操作
}

这才是架构之美：井然有序，职责分明。

✳️ 3. 解耦：拒绝“连体婴”，拥抱“模块自治”

设计的第三个关键是**“解耦”**。

程序设计的目标不是“跑得快”，而是“能换腿”。

什么叫耦合？

public class OrderService {
    public void createOrder() {
        EmailUtil.sendEmail("order created");
        KafkaProducer.send("order_topic", "created");
    }
}

如果现在你不用 Kafka 改用 RabbitMQ，或从 Email 改为短信通知，怎么办？

所以我们需要使用接口 + 策略的方式：

public interface Notifier {
    void notify(String msg);
}

public class EmailNotifier implements Notifier {
    public void notify(String msg) {
        // 发送邮件
    }
}

public class SmsNotifier implements Notifier {
    public void notify(String msg) {
        // 发送短信
    }
}

然后 OrderService 中只依赖接口：

public class OrderService {
    private Notifier notifier;

    public OrderService(Notifier notifier) {
        this.notifier = notifier;
    }

    public void createOrder() {
        // ...
        notifier.notify("下单成功");
    }
}

你看，换腿不伤身，这才是架构思维。

三、从写逻辑到做设计，程序员的心智跃迁

维度	写逻辑	做设计
思维方式	步骤式流程	模块式抽象
关注点	怎么实现功能	系统是否稳定、易扩展
可扩展性	差（加功能必改原逻辑）	高（可插拔、可配置）
代码组织	混乱耦合	分层清晰
复用性	低	高
新人上手	难	容易