LTS: DDD 表达实践

尝试使用一些 DDD 知识描述工作中遇到的问题，看看能否学习到东西

问题1

2024-07-04 在 review make 富文本代码的时候，发现它把 “header-one”，“header-two”，"header-three" 在代码里用 “H1”，“H2”，“H3”表示了。 当时我批评他是偷懒，没有保证数据一致性。现在想想我并没有把问题想明白，道理完全讲清楚。 首先，make 为什么会写会用 H1 缩写来替代 header-one？ 背景：make 需要开发快捷键快速改变当前文本 block 类型的需求 猜测：他是基于我之前写的测试代码继续开发的，那时我写的类型是 header-one | header-two | header-three，他那时肯定不会改。而 header-one | header-two | header-three 在产品里的表达是 H1,H2,H3，它们两者在语言上并没有太大差异，那么自然在开发过程中，他会趋向使用产品的表达来填满代码里的表达 理解：我后面想如果全面改用 H* 可不可以，当然可以。它的改变就是对业务中文本类型的一次研发层领域知识改变。只是现有的文本数据和代码上下文已经被 header* 占据了，如果只是表达发生了改变，从而想让 header* 转向 H* ，理由显得无足轻重。毕竟我们的大脑已经对 header* 和对应业务表达的联系有了清晰的认知。所以我们需要在研发行为开始之前，让产品和研发共同确认好业务领域知识，如产品里用 H1 H2 H3，代码里用 type HType = H1 | H2 | H3，从而避免未来领域知识升级带来的代码升级难题

问题2

2024-07-06，我其实在解释以下问题，写下了问题1的思考 今天周六，我闲来无事看了看 rengyj 在做什么。原来他在拖拽列表组件。我问他怎么不用 xxxxxxxxxd 之前用的那个 lib，他说那个看了不满足需求。自己现在在参考 antd 实现，最终想要实现和 xxxxxxxxxp 效果一样的拖拽功能组件。因为看不懂 xxxxxxxxxp 代码，所以自己重新写。 跟他说明了问题所在，走错了路后，指导了正确解法是什么后，他应该正在走对路 解释如下

1. 自己写顶多覆盖到 80 % 的功能，并且正确性无法保证，给研发和测试的压力都很大
2. 不基于源代码想要还原 xxxxxxxxxp 的手感是很困难的事情
3. 根本问题：产品提出想要 xxxxxxxxxp 的效果，研发却因为 xxxxxxxxxp 代码复杂，产生了畏惧心理，而不用 xxxxxxxxxp 的代码，导致解决问题方向发生了偏差 从 DDD 的角度看，是研发过程中缺乏领域专家对研发进行指导，导致研发领域知识建模无法与产品领域知识重合