业务系统设计的本质

业务系统的挑战和价值

业务系统的真正的挑战并不是技术，技术只是一个工具，基本上都有成熟的组件来使用。业务系统真正的价值也不是技术，而是实现了对企业有价值的业务逻辑。所以一个业务系统真正的挑战在于如何快速的支撑业务。完成一个可以支撑业务的系统设计好像并没有难度，但在不断地系统需求演进中，很多系统变得越来越难以维护，BUG越来越多，代码越来越难以读懂，响应需求越来越慢。需求是系统的试金石，系统应该像个有机体一样，在不断地需求中不断进化，而不是无序复杂度暴涨。而业务系统可以进化的设计的核心在于真正理解了业务的本质，不然根上都错了，所有的努力可能都是负资产(系统变得更复杂，更难以维护)，本文的重点是解释为什么需要认识业务的本质，以及如何针基于业务的本质进行设计。下面通过一个简单的示例进行说明(示例为简化说明的虚拟项目)。

被动响应需求式开发的示例

比如在一个电商系统中，我们的诉求是要限制一个商品的购买数量，需要根据地区的限制最多购买N件，我们如下设计了地区限制模块。

伴随需求发展，我们需要根据门店限制购少购买N件，我们新加入门店限制模块。

通用化设计

面对这两个需求，我们来分析一下：

• 地区有最多购买N件，门店是否也可能最多限制N件呢？答案是非常可能的。
• 门店有最少购买N件，地区是否也可能限制最少购买N件呢？嗯，可能有，也可能没有。
• 除了地区限制，门店限制，后面有没有可能在其他维度上限制呢？比如商品分类？答案是肯定的。

如果我们系统做的更灵活一点，我们只是在一定维度上进行限制，并不关心是商品，地区，还是门店。只要告诉我维度类型+维度值，以及如何限制，我就可以限制。系统没必要耦合商品，地区，或门店。这样上面的问题不就都解决了吗？开发量也并没有变大，而且能支持更多的场景，我们改进系统的设计如下。

如上图所示，通用的限制模块中，不允许有如下代码，也就是任何限制逻辑都不应该耦合具体的维度

plaintext if(限制维度=门店){ doSomething(); }

为了完成上面不同维度的不同需求，可用通过下面的配置化来解决。

| 维度 | 最小购买限制 | 最大购买限制 | | --- | --- | --- | | 地区 | 不可用 | 可用 | | 门店 | 可用 | 不可用 |

面对需求变更，比如门店也要限制最大购买数量，我们就可以变更配置来实现，代码是不需要变动的：

| 维度 | 最小购买限制 | 最大购买限制 | | --- | --- | --- | | 地区 | 不可用 | 可用 | | 门店 | 可用 | 可用 |

如果新增加了维度需求，比如按照商品分类进行限制最大购买数量，同样也只需要变更配置：

| 维度 | 最小购买限制 | 最大购买限制 | | --- | --- | --- | | 地区 | 不可用 | 可用 | | 门店 | 可用 | 可用 | | 商品分类 | 不可用 | 可用 |

如果新增了功能需求，比如按照地区，每个用户只能购买N件，我们开发了按照用户购买N件的需求，然后配置地区可用

| 维度 | 最小购买限制 | 最大购买限制 | 每用户最多购买N件 | | --- | --- | --- | --- | | 地区 | 不可用 | 可用 | 可用 | | 门店 | 可用 | 可用 | 不可用 | | 商品分类 | 不可用 | 可用 | 不可用 |

如果门店哪天有需求也要支持每用户最多购买N件，新开发的功能可以直接复用，而不需要变更代码，只需要变更配置如下：

| 维度 | 最小购买限制 | 最大购买限制 | 每用户最多购买N件 | | --- | --- | --- | --- | | 地区 | 不可用 | 可用 | 可用 | | 门店 | 可用 | 可用 | 可用 | | 商品分类 | 不可用 | 可用 | 不可用 |

原理总结

整个设计的过程，分成三个阶段，看山是山，看山不是山，看山是山。

阶段一：看山是山。

嗯，我懂了业务，限制购买分成限制地区和限制门店，地区限制最大购买数，门店限制最小购买数。就是这个样子，这就是山。

阶段二：看山不是山(怀疑)

啊，伴随业务发展，系统好像不应该这样做，不应该是分别限制地区和门店呀，不应该是这个样子，原来认为的山好像不是山。

阶段三：看山是山

嗯，经过分析，原来是可以通用设计，使用限制维度和维度值来表示，各种不同的限制逻辑都长在这个通用模型上。嗯，这才是山，而原来的山，是可以通过新的山配置出来的。嗯，这就是山，只是此山非彼山。