延期没问题，希望能精益求精。

问一下小米售后呢

DDD 的核心就是统一业务和研发的理解，实现一个模型贯穿业务和技术。
是非常理想的建模和开发过程，不过对于业务分析师、架构师和开发人员的要求太高了，很难落地。

@pjee #2 下个华医通，早起抢号吧。
或者花点钱找黄牛。。。

华西牙科啊。。。

举得场景都很扯啊。。。
AI 补全目前看靠谱的场景都是审美类的，真正用在治病、科考这些方面的数据都要求严谨，缺失的数据反而是说明问题的重点，你这有点给维纳斯补手臂的意思，画蛇添足啊。

对这个现象我有一个 90%可能性的猜测：
这个表本来有 36w 行数据，但是因为某些物理损坏，在聚集索引中丢失了中间 3w 行记录的引用。这时候从表的属性看，数据仍然有 36w 行，而且其他非聚集索引仍然完整指向了这 36w 行记录。
当使用聚集索引时，中间的 3w 行数据查不到，但是用非聚集索引查找时能查到所有 36w 行记录。

我尝试重建聚集索引，数据库引擎为了保持数据完整性，把 3w 行记录删除掉，并且通知其他非聚集索引重建。
之后所有方式的查询结果一致，但是 3w 行记录就消失了。

@xsm1890 #3 厉害了，我又看了一下，count （）出来的总数没变，只是数据表属性页里面的条数少了 3w 。
而且按 id 排序的话，发现中间 58000 到 90000 的 id 缺失了。
如果总数没变，不知道这些 id 跑到哪里去了。。。

点进去，左边的职能类别好多重复的。。。显得不够专业啊。。。

@roufan1024 #5 很好，很有精神。就不浪费彼此时间了。

建议 OP 把自己想说的再捋捋，上一句在说人力成本的差距，下一句就跳到伟人划圈，再下一句是外企撤出，分段后又跳转到资金安全风险管理。。。

感觉是想说的东西太多，一团乱麻，不要指望网友能帮你把思路理清楚。只有你先想清楚了才能跟别人交流。

嗯，所以说锅在头文件。
重复引用什么的都是后话。。。

01 背包问题是解决一个背包最大化的算法吧。
能推广到 OP 这种要求 n 个背包最大化的场景吗？