为什么模型应该更具抽象概念，而不是被业务属性束缚

好帅的舅舅

昨天在项目群里讨论问题时，有个同事提到一个观点让我印象深刻：“模型应该更具抽象概念，不应该赋予业务属性。”简单的一句话，却揭示了一个我们在开发中经常忽略的重要原则。
今天就来聊聊这句话背后的深意，以及它为什么值得我们在模型设计中深刻反思。

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

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

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

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

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

02 为什么模型设计要“去业务化”？
在项目开发中，把模型设计得过于贴合具体的业务场景，很容易埋下隐患。以下是几个关键原因：
1. 降低系统耦合，保持灵活性业务逻辑是动态的、经常变化的。如果模型被绑定到具体业务属性上，那么每次业务调整时，模型都可能需要修改，导致系统的其他部分被连带影响。
举个例子：
如果“用户模型”包含“订单数量”字段，那么订单系统的改动会直接影响用户模型，甚至需要改动数据库结构。
这样的耦合让系统变得非常脆弱。而抽象模型通过专注本质，减少了这种相互牵绊的风险。
2. 提高模型复用性一个好的抽象模型，可以在不同的业务场景中被复用。比如，一个抽象的“用户”模型，可以应用于：

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

如果模型里包含了业务属性，比如“购物车内容”或“朋友圈动态”，那么它就很难跨越场景复用，导致代码和逻辑的重复。
3. 支持业务演进在一个快速变化的业务环境中，需求的变化往往比我们预期得更频繁。如果模型绑定了过多的业务属性，每次需求调整都会牵一发而动全身。
相比之下，抽象模型更像是一块稳定的基石，业务逻辑可以围绕它自由演变，而不会对核心结构造成过多干扰。

03 如何在实践中实现抽象模型设计？
知道了抽象模型的优势，那该如何在实际开发中实现呢？以下是一些可操作的设计方法：
1. 专注对象的本质设计模型时，尽量只保留那些反映对象本质的属性。例如：
用户模型只包含“用户名”、“邮箱”等基本信息，而不是“是否参与某活动”这样的业务字段。
这样的设计可以保证模型的稳定性，避免被业务需求牵着走。
2. 业务逻辑外移将复杂的业务逻辑从模型中移到服务层或领域对象中。比如：
“用户的订单统计”应该由订单服务来负责，而不是直接嵌入用户模型。
通过分层设计，我们可以将模型和业务逻辑解耦，确保模型的纯净。
3. 使用组合代替继承当需要扩展模型功能时，优先使用组合，而不是直接在模型中添加字段。例如：
用一个单独的“会员信息”模块，来扩展用户的会员功能，而不是直接在用户模型中添加“会员等级”。
4. 借助接口与领域驱动设计通过定义接口或领域对象，避免模型设计受限于具体实现。例如：
这样可以灵活地扩展用户模型的功能，而不会破坏其核心结构。

04 典型误区与应对策略
尽管“模型抽象化”的理念很好，但在实践中我们可能会遇到以下问题：
1. 过度抽象如果抽象过度，模型可能变得过于笼统，反而无法满足实际需求。例如，将所有业务都抽象为“实体”或“资源”，最后反而失去了模型的意义。
应对策略： 抽象时，关注对象的本质属性，适度平衡抽象与现实需求。
2. 忽略业务的特殊性有时，开发者为了保持模型的抽象性，完全忽略了业务需求的复杂性，导致实现过程反而更加繁琐。
应对策略： 结合领域驱动设计（DDD），通过分层架构，让模型抽象与业务逻辑合理分工。

05 抽象模型是稳定的，业务逻辑是可变的
正如那位同事说的，模型设计应该专注于抽象概念，而不是被业务属性束缚。这是一个技术原则，也是一种长远的系统设计哲学。抽象模型就像稳定的地基，支持着不断变化的业务需求。
在未来的开发中，不妨多花一些时间，思考你的模型是否过于依赖业务属性？是否可以更抽象、更独立？相信这些思考会让你的系统更稳健，更灵活。
模型是稳定的，业务是灵活的。把握这两者的界限，是一个开发者真正成熟的标志。
本文由 @好帅的舅舅 原创发布于人人都是产品经理，未经授权，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。