我想记录代码中的某些模式，以建立一致的术语（以便简化关于软件的通信）。然而，我不确定，在哪里定义给定的术语。为了达到同一水平，举一个例子：
我有一个代码生成器。此代码生成器从Parser接收某个InputStructure（是的，名称InputStructure可能不太理想）。这个InputStructure然后被转换成各种后续的数据结构（如验证过程的抽象描述）。这些数据结构中的每一个都可以转换成相同数据结构的另一个值，也可以转换为下一个数据结构。这在某种程度上应该听起来像管道和过滤器。
考虑到这一点，我称之为一种操作，它采用数据结构并构建相同数据结构的值并进行转换，而我称之为操作，该操作采用数据结构并产生不同后续数据结构的派生。导出包含代码的字符串的最后一步称为发射。 （所以，总的来说，代码生成器采用输入结构和变换，变换，派生，变换，派生和最终发射）。
我认为强调这些术语会对通信产生好处，因为那样很容易谈论事情。如果你听到“转换”，你知道“好的，我只需要考虑这两个数据结构”，如果你听到“发射”，你知道“好吧，我只需要知道这个数据结构和目标语言。”。
但是，我在哪里记录这些模式？当前的代码库使用访问者并提供类ValidatorTransformationBase <ResultType>（或InputStructureTransformationBase <ResultType>，等等）。
我真的不想将这些术语的定义添加到接口中，因为在那种情况下，我不得不在每个接口上重复自己，这显然违反了DRY。
我正在考虑通过添加更多的接口，强调变革与导之间的区别（我将不得不考虑对TransformationBase类一个更好的名字，但我可以做这样想ValidatorTransformation延伸ValidatorTransformationBase <验证>，或ValidatorDerivationFromInputStructure扩展了InputStructureTransformation <Validator>）。
我还认为我应该为已经存在的doxygen文档添加一个自定义页面，如“Glossary”或“Architecture Principles”中所包含的原则。唯一的缺点是，贡献者需要找到这个页面才能真正了解这一点。
我是否缺少可能性或者我在这里判断错误？
- 问候，Tetha