我学习任何东西的时候都喜欢琢磨要学东西的精髓，也就是它最有效的部分。以前很喜欢太极拳，以前经常跟一些圈内的拳友交流拳术的精髓，也遇到过不少的行家里手，他们口中常说太极的心法就是“内外相合，上下相随，阴阳相济”等，让人觉得很对的但又无从入手的话。有个高手说过，这些心法就是太极拳的精髓，但这些精髓往往蕴藏在有限的招式里，不要被招式迷住眼，如果一套拳法招式太多，往往精髓就会被湮灭掉了，结果是招式练得越多，有可能功夫越是稀疏平庸。
我们最近在做一个使用大模型从存量c代码生成DDD模型，然后再从DDD模型转换到rust语言的项目，即要高效的从海量存量c遗留代码锈化成rust，又要保证这一过程rust代码的高质量，不希望转换成一批披着rust外衣的c。
万事开头难，如何使用大模型从存量c语言生成DDD呢？大家知道架构设计本身是消除high leve的重复，然后抽象提炼的过程，这种通读代码识别架构重复并抽象提炼恰恰是大模型最不擅长的。
另外DDD的体系非常庞大，大模型又该从哪个角度入手呢？
这时候必须做减法，需要我们换个角度，从DDD设计的精髓入手，看看能否得到一些思路。
上图是DDD设计的整体框架，上下看分成问题域和解决方案域，左右看看分成战略设计和战术设计。
在使用存量c代码反向DDD建模时，如果把DDD建模中的要素一一打开，可能很快失去焦点，最后弄了一大堆DDD概念，而形不成一个真正可以生成代码的框架。
需要从本质看，DDD建模精髓就是处理领域的两类词汇：
1、名词
a、含义
这些名词代表领域中的实实在在的概念，这些概念粒度不同，有大有小，大的可以是聚合、实体、值对象，小的可以是其中的属性。
b、关系
概念和概念之间的关系，最常见的比继承、关联、依赖、聚合、组合等。
2、动词
a、含义
代表了领域中的行为，这些行为粒度也是同样大中小不同，其中大的表示系统级的行为，比如Application Service，中的表示Domain Service，小的表示概念的职责（聚合、实体、值对象的贴身方法等）。
另外还有些通用业务行为common和通用垂直行为util等。
b、编排
行为把概念的职责、公共服务等进行编排和组合，从而实现业务功能的完整性、一致性（事务）。
以上就是DDD设计的精髓，按着这个思路，对于存量c语言我们尝试一种使用大模型自动建模的方式：
1、使用大模型对整个c源码进行逐文件扫描，分别抽取其其中名词（主要来源自数据结构、变量（全局变量、局部变量）、函数名中的宾语）
2、对名词按语义相同或语义相近进行合并汇总。
3、对合并后的名词进行梳理后建立关系，形成领域对象：聚合、实体、值对象，并建立领域对象之间的引用包含关系。
此时可能需要辅助DDD专家人工修正，最后生成领域概念。
4、抽取源码中的动词/动宾结构（主要来源函数名中的谓语）
5、对动词/动宾按语义相同或语义相近进行合并汇总成领域行为。
6、对合并后的领域行为按粒度进行Application Service、Domian Service、名词相关概念的职责进行归属。这里也可能需要DDD专家的人工修订。
至此DDD模型的框架基本就位。
tips：以上过程都需要满足原系统是静态状态丰富，动态状态较少的特征等适于DDD建模的场景；另外原代码需要是命名规范、clean code足够好的代码。
接下来就可以在行为中调用领域概念中的职责形成业务功能。
最后，还要把领域概念和领域行为归并放置到分层架构中。
小结
DDD的精髓就是对领域建模（正向设计）或存量代码（反向设计）中的名词和动词/动宾的处理。
对名词的处理生成领域概念，并对概念进行组合产生关系；
对动词/动宾的处理生成领域行为，并对行为进行编排。
从而实现条理清晰，结构明确，易于维护，易于理解，和业务对齐的DDD架构。
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/424037.html
