功能决定如何建模：B2C电商案例

[[领域模型决定功能扩展性：人事管理系统案例]]说明了”领域模型决定功能扩展”这个方向，反过来同样成立：”功能扩展”驱动”领域建模”——想要系统具有可扩展性，领域建模时就应该以”现在就要的功能+未来可能需要的功能”作为建模思维的驱动力，而不是先抽象后验证。书中用一个B2C电子商务网站的商品分类建模过程，演示了这个反向驱动关系如何具体落地，一共经历三轮迭代。第一轮：为支持”电脑办公”（商品大类）、”笔记本”（商品子类）这类当前功能，模型定义了Category和Subcategory两个类分别代表大类和子类——但这个设计把两级商品分类”做死了”：如果只是笼统地批评”这样设计不好”，很容易和同事吵起来，必须具体指出不适合的场景才有说服力。第二轮：当出现商品分类层次超过两层的功能场景时，第一版模型明显支持不了，于是模型被改进为定义一个可以递归包含自身的Category类，商品类目层次可以是1到N层，灵活性大幅提升，第一轮设计被明确否定。第三轮：面对一个”未来可能需要”的功能——一本书可以同时属于”红色读物”“纪实文学”“小说”多个类目，读者点击某个主题名字就能看到该主题下所有图书——第二轮的Category自包含关系必须从”一对多”升级为”多对多”自包含，第二轮设计被升级。这个渐进演化过程揭示了一个反直觉的教训：”从头到尾的抽象思维”是设计高手都容易掉进去的”美丽陷阱”——抽象模型看起来干净漂亮，但真正驱动模型该长成什么样的，始终是具体、有证据的功能需求（包括已确定的未来功能），而不是脱离场景的抽象美感。