过度设计

核心问题

我们是在建设未来，还是在为幻想付税？

工程困境

客户只需要课程购买和播放，你却先设计了：

workflow engine
plugin system
generic policy runtime
multi-tenant permission graph

半年后，业务没长到那里，团队却每天为这套抽象付学习成本。

思想模型

过度设计不是“写多了”，而是让系统背上了还不存在的问题。

好架构给未来留门。坏架构替未来盖宫殿。

好判断

判断一个设计是否过度：

当前是否有至少 2-3 个真实用例？
未来变化方向是否清楚？
抽象是否能让调用方知道更少？
如果不用它，系统是否仍然能清楚表达需求？

Atlas 案例

课程访问来源现在只有购买。不要立刻做“UniversalAccessEngine”。先写清楚 Purchase。等订阅、企业分配、兑换码都出现，再抽 CourseAccessGrant。

Atlas Action

找一个“为了未来”加的抽象。写下它已经服务的真实用例。如果少于两个，考虑先降级为具体实现。

小结

未来需要选项，不需要纪念碑。