永远不要试图用战术上的勤奋，去掩饰你战略上的懒惰。

——雷军

背景

在设计团队协作存储模块时，我遇到了很多问题。

许多想法在我脑海中打架：

• 我想到非结构化的存储在 MinIO 中的文件，它们需要 MySQL 中涉及一个元数据表来进行维护吗？
• 如果需要，那么涉及到文件夹，文件夹这个抽象的概念又怎么引入这个表呢？
• 文件从属文件夹的设计又要怎么实现？在代码逻辑上，循环嵌套又要怎么查询呢？如果要修改一些文件，比如说涉及到移动、复制、删除从属，在代码实现上不是很麻烦吗？
• 权限控制呢？……

想到这些庞大的设计上的问题，以及各种嵌套的复杂概念，我几乎有些望而却步了。但是，回过头，我突然想起来，我原本设计这个模块，是为了团队协作的，那么——有必要设计那么多层的文件夹从属关系吗？要不设计最多三层，可以降低复杂度吧？

再往下想，三层？为什么不是两层、甚至一层？我和 AI 探讨了这些设计，在做权衡的过程中，突然，它提到了一个概念 DDD(Domain-driven Design)。

——看看现在的协作工具（如 Notion、飞书）是怎么做的？我们几乎可以看到，它们都在刻意淡化传统文件夹的概念，而改用“空间/项目/文件”进行划分，使用“标签、状态”来进行分类……

这是什么意思呢？意思是，我们假定——这些抽象概念才是我们的设计目标“团队协作”的核心！我们用这些抽象来人为划定范围去控制用户的行为，同时能够很大程度上降低我们的建设复杂度……

嘿！我们原本是怎么想的？既然要写一个系统，就必须支持技术上的各种可能（无限层级、无限嵌套）。但是，显而易见，这种设计是很复杂的。——更重要的问题是，我们真的需要那么复杂的功能吗？反而，通过认为划定了这些空间，我们获得了巨大的优势——

1. 业务逻辑更清晰了。用户的认知负载也降低了。根据这些划分，天然地知道某个部门的某个文件该放在哪里，而不是自建复杂的文件夹，便于共同协作。
2. 我们的数据库表设计变得更加清晰了！原本可能涉及到复杂的表查询，现在会变得更加扁平。查询会非常清晰！也容易拓展并发控制和锁设计！
3. 系统的骨架变得更加清晰、轻量和好维护……