避免过度设计：让 .NET 开发回归简洁高效

云中小生

发布于 2025-08-24 08:57:22

12000

代码可运行

运行总次数：0

代码可运行

★ 过度设计就像给咖啡杯装上 GPS 追踪系统——看似强大，实则徒增负担。在 .NET 开发中，我们常因追求“完美架构”而陷入设计泥潭。以下是如何识别并避免这一陷阱的实用指南： ”

🍀 过度设计的典型症状

★

接口泛滥症： 每个类都强制配套接口 (IUserService, IUserServiceImpl)，却仅有一个实现
抽象强迫症： 三层架构项目里，CreateUser 请求竟穿越 6 个抽象层才触及数据库
未来幻想症： 为“可能”支持多数据库提前引入复杂仓储模式，实际仅用 SQL Server
模式膨胀症： 在 CRUD 功能上强行应用 CQRS/事件溯源，徒增消息队列与事件存储负担

”

💡 务实设计四原则

1. 拥抱 YAGNI

// 与其预先抽象
public interface IDataStorage { void Save(User user); }
public class CloudStorage : IDataStorage { ... }

// 不如直截了当
public class UserService
{
    public void SaveUser(User user)
    {
        // 直接实现存储逻辑
        _dbContext.Users.Add(user);
    }
}

何时升级？ 当需要支持新存储类型时再提取接口，重构成本远低于维护无用抽象。

YAGNI 简介：

YAGNI 是 "You Ain’t Gonna Need It" 的缩写，是极限编程（XP）中的核心原则之一。它强调 “只在当前需要时才实现功能，避免过度设计”。 简单来说，就是不要为未来可能用到的功能提前写代码，除非需求已经明确存在。

YAGNI 的核心思想：

不做无用功： 只解决当前问题，不为假设的未来需求编写代码。
减少浪费： 避免因过度设计导致代码臃肿、维护成本增加。
拥抱变化： 未来需求可能变化，提前实现的代码可能最终无用或需重构。

YAGNI 的作用：

降低复杂度： 未经验证的功能会增加系统复杂性。
节省时间： 将精力集中在真正重要的功能上。
灵活性： 未来需求变化时，无需删除或修改冗余代码。

2. 分层适可而止

📁 Project
├─ 📁 Models // 领域模型
├─ 📁 Services // 核心业务逻辑
├─ 📁 Controllers // Web API
└─ 📁 Infrastructure // 数据库等实现

✅ 合理：领域层引用基础设施 ❌ 过度：基础设施层通过事件反向通知领域层，引入循环依赖

3. 警惕 DDD 陷阱

10 人以下团队开发 CMS 系统？慎用完整领域驱动设计
避免为每个值对象定义专属微服务（真实教训！）

4. 让框架做繁重工作

// 过度设计：
public class CustomLogger : ILogger
{
    public void Log(string message)
    {
        // 手写日志逻辑...
    }
}

// 务实选择：
builder.Services.AddSerilog(); // 直接集成成熟日志库

⚖️ 设计决策平衡表

场景	过度设计方案	务实方案
用户管理模块	抽象出IUserRepository	直接在UserService中使用 EF Core
小型电商支付	引入事件溯源+CQRS	事务脚本+数据库事务
API 版本管理	自定义版本路由中间件	使用ApiVersion 特性

🔄 渐进式设计实践

从具体实现开始： 先写出可运行的代码
痛点驱动重构： 遇到扩展需求再抽象（如新增支付渠道时提取 IPaymentProvider）
利用编译器： 将类暂时设为 internal 而非 public，限制过度暴露
定期技术债务审计： 每迭代周期清理无用抽象

// 初始实现：简单直接
internal class EmailSender
{
    public void SendWelcomeEmail(string email) { ... }
}

// 当需要短信发送时重构：
internal interface INotificationSender
{
    void Send(string target);
}

internal class EmailSender : INotificationSender { ... }
internal class SmsSender : INotificationSender { ... }