AI + DDD + Laravel 开发独立站商城挑战 (第三周)

原本这应该是第二周的内容，但因为业余时间有限，以及这个方法相对陌生，还需要参考多一些的资料，第二周该完成的东西就拖到第三周来发了

在上一篇帖子里有不少朋友反馈说 DDD 更适合大项目，小业务不需要，我也很认同，但是现在有一个 AI 变量可以使用，在编码方面更想试一试 AI 主导，至于人的智力就主要放在设计规划上。
最近发的这几篇帖子里 AI 才是主语，DDD 只是助动词。

不过我也做好了心理准备，实际开发时间可能比传统架构传统方式花的时间更多,大概是这几个因素

1. DDD 架构可参考的经验和学习资料并不是那么丰富，可参考资料较少
2. DDD 架构本身需要消耗的时间精力大于传统方式
3. AI 来主导编码目前也同样缺少更多的学习、参考资料
4. 目前对于 AI 工程化的基础设施其实很少，并没有那么丰富的开发工具来辅助进行层层解耦并实现流程自动化。这是工具层面的因素，在 AI 驱动开发的流程上缺少自动化工具
5. 自己对这块也没什么实践经验，这是熟练度因素
6. 自己也是兼职摸索一下，偶尔懒惰一下，精力方面投入的也没那么多

基于上述几点，可能这一次的尝试在时间上会不如传统开发，但如果熟能生巧通过这种尝试积累了一些 AI 驱动的经验和一些自动化工具来辅助开发之后，情况或许就会变得不一样了……..

目前不管那么多，先做个垃圾出来再说

这周的大概任务是修复最开始的一点猜想上的小错误，即 AI 生成用例（这其实是个很矛盾的东西，如果 AI 能搞懂业务必然需要很详细的提示词，但如果提示词够精确，那就约等于完成了一遍用例分析……. AI 在这块的价值就只剩把用例描述转述成 UML 了）

AI 可以生成 UML 图表，但不能代替人做用例分析

用例分析在DDD中的重要性

即使在普通架构中，业务分析也是编码的先导，在 AI + DDD 的架构上，用例分析实际上可以贯穿研发全程，因为完整全面的用例分析实际上是天然的提示词素材，有了这个提示词去生成领域模型、单元测试都是很方便快捷的。
如果用例够精细精准，那么 vibe coding 的准确性也会足够高

用例分析这部分需要做两件事

1. 业务用例
2. 系统用例

业务用例这部分原则上要更贴近业务层面而不是代码层面

先有业务用例，之后利用业务用例作为输入来编写系统用例（这部分大概也能让 AI 代劳，但我还没尝试），系统用例可以包含 extend 和 include 这些关系

（经过这段时间对业务分析、用例分析的尝试和练习，发现最近提示词水平也提高了，对于小功能小需求，能一次性编写出完整翔实包含边界情况处理的提示词，对于一些工具代码能一次对话就拿到想要的结果，不需要多轮对话迭代了，提示词真的会是一项比较重要的技能，待会到评论区发一下今天刚编写的提示词，可能提示词最后也会沉淀出一种 “设计模式”，或者已经有了只是我没找到？）

业务用例

业务用例和系统用例的方法论谷歌也能搜到一些，不多说，直接开画

业务用例讲究贴合业务语言，先浅浅地描述一下

之后画个泳道图来描述一下流程

再之后开始系统用例分析

系统用例

系统用例就开始有点领域代码的边界范畴了，也确实是进行编码的下一步准备

事实上到这里，业务情况和代码规划的轮廓就已经出来了，可以通过用例来分析出子域

画出图之后接着完成详细一点的系统用例

之后是商品管理里面的用例

作为 cms 页面管理也是必不可少

之后是供货渠道

感觉这周完成的东西瑕疵也不少，如果后面会有实际影响再补上去，前后变动可能会比较多……