在产品开发中，我们常常会忽略一个重要的原则：“模型应该更具抽象概念，不应该赋予业务属性。”简单的一句话，值得我们深思。本文作者分享了他对这句话的理解和思考，大家可以参考。

昨天在项目群里讨论问题时，有个同事提到一个观点让我印象深刻：“模型应该更具抽象概念，不应该赋予业务属性。”简单的一句话，却揭示了一个我们在开发中经常忽略的重要原则。

今天就来聊聊这句话背后的深意，以及它为什么值得我们在模型设计中深刻反思。

01 什么是模型的“抽象概念”？

在软件开发中，模型是现实世界在系统中的抽象表达。比如，“用户”这个模型在最抽象的层面上，可以定义为：

• 用户名
• 密码
• 邮箱
• 唯一标识（ID）

这些属性是用户的本质，而与具体的业务无关。与之相对的是业务属性，比如：

• 用户下了多少订单。
• 用户的会员等级。
• 用户是否参与了某次活动。

这些是与业务相关的逻辑，不属于用户的本质。模型的抽象性，就是专注于本质属性，而不是具体业务场景中那些容易变动的部分。

02 为什么模型设计要“去业务化”？

在项目开发中，把模型设计得过于贴合具体的业务场景，很容易埋下隐患。以下是几个关键原因：

1. 降低系统耦合，保持灵活性

业务逻辑是动态的、经常变化的。如果模型被绑定到具体业务属性上，那么每次业务调整时，模型都可能需要修改，导致系统的其他部分被连带影响。

举个例子：

如果“用户模型”包含“订单数量”字段，那么订单系统的改动会直接影响用户模型，甚至需要改动数据库结构。

这样的耦合让系统变得非常脆弱。而抽象模型通过专注本质，减少了这种相互牵绊的风险。

2. 提高模型复用性

一个好的抽象模型，可以在不同的业务场景中被复用。比如，一个抽象的“用户”模型，可以应用于：

• 电商系统：用于下单和订单管理。
• 社交平台：用于关系网络和用户动态。
• 企业内部系统：用于人力资源管理。

如果模型里包含了业务属性，比如“购物车内容”或“朋友圈动态”，那么它就很难跨越场景复用，导致代码和逻辑的重复。

3. 支持业务演进

在一个快速变化的业务环境中，需求的变化往往比我们预期得更频繁。如果模型绑定了过多的业务属性，每次需求调整都会牵一发而动全身。

相比之下，抽象模型更像是一块稳定的基石，业务逻辑可以围绕它自由演变，而不会对核心结构造成过多干扰。

03 如何在实践中实现抽象模型设计？

知道了抽象模型的优势，那该如何在实际开发中实现呢？以下是一些可操作的设计方法：

1. 专注对象的本质

设计模型时，尽量只保留那些反映对象本质的属性。例如：

用户模型只包含“用户名”、“邮箱”等基本信息，而不是“是否参与某活动”这样的业务字段。

这样的设计可以保证模型的稳定性，避免被业务需求牵着走。

2. 业务逻辑外移

将复杂的业务逻辑从模型中移到服务层或领域对象中。比如：

“用户的订单统计”应该由订单服务来负责，而不是直接嵌入用户模型。

通过分层设计，我们可以将模型和业务逻辑解耦，确保模型的纯净。

3. 使用组合代替继承

当需要扩展模型功能时，优先使用组合，而不是直接在模型中添加字段。例如：

用一个单独的“会员信息”模块，来扩展用户的会员功能，而不是直接在用户模型中添加“会员等级”。

4. 借助接口与领域驱动设计

通过定义接口或领域对象，避免模型设计受限于具体实现。例如：

class User:

def __init__(self, user_id, username):

self.user_id = user_id

self.username = username

class MembershipDetails:

def __init__(self, level, expiry_date):

self.level = level

self.expiry_date = expiry_date

这样可以灵活地扩展用户模型的功能，而不会破坏其核心结构。

04 典型误区与应对策略

尽管“模型抽象化”的理念很好，但在实践中我们可能会遇到以下问题：

1. 过度抽象

如果抽象过度，模型可能变得过于笼统，反而无法满足实际需求。例如，将所有业务都抽象为“实体”或“资源”，最后反而失去了模型的意义。

应对策略： 抽象时，关注对象的本质属性，适度平衡抽象与现实需求。

2. 忽略业务的特殊性

有时，开发者为了保持模型的抽象性，完全忽略了业务需求的复杂性，导致实现过程反而更加繁琐。

应对策略： 结合领域驱动设计（DDD），通过分层架构，让模型抽象与业务逻辑合理分工。

05 抽象模型是稳定的，业务逻辑是可变的

正如那位同事说的，模型设计应该专注于抽象概念，而不是被业务属性束缚。这是一个技术原则，也是一种长远的系统设计哲学。抽象模型就像稳定的地基，支持着不断变化的业务需求。

在未来的开发中，不妨多花一些时间，思考你的模型是否过于依赖业务属性？是否可以更抽象、更独立？相信这些思考会让你的系统更稳健，更灵活。

模型是稳定的，业务是灵活的。把握这两者的界限，是一个开发者真正成熟的标志。