在Golang实践DDD时，如何避免使用持久层工件污染域模型？_Go_Domain Driven Design

在Golang实践DDD时，如何避免使用持久层工件污染域模型？

go domain-driven-design

在Golang实践DDD时，如何避免使用持久层工件污染域模型？,go,domain-driven-design,Go,Domain Driven Design,我正在使用Golang练习DDD，不想用bson标记之类的持久性工件污染我的模型，也不想用json标记污染我的模型，json标记与来自端点的编码/解码数据有关不必在三个地方定义结构，实现这一点的优雅方式是什么我已经将我的模型嵌入到我的模型的持久层版本中，它包装了模型并添加了一个mongo特定的ID字段，但是嵌入意味着我必须将我的mongo标记放在我的模型定义中，我的端点的enc/dec结构也面临同样的问题。我想你可以在域对象和持久层之间创建一个api边界，因此你的解组代码将使用标记的结构，然

我正在使用Golang练习DDD，不想用bson标记之类的持久性工件污染我的模型，也不想用json标记污染我的模型，json标记与来自端点的编码/解码数据有关

不必在三个地方定义结构，实现这一点的优雅方式是什么

我已经将我的模型嵌入到我的模型的持久层版本中，它包装了模型并添加了一个mongo特定的ID字段，但是嵌入意味着我必须将我的mongo标记放在我的模型定义中，我的端点的enc/dec结构也面临同样的问题。

我想你可以在域对象和持久层之间创建一个api边界，因此你的解组代码将使用标记的结构，然后调用

NewDomainObject（未签名的.X…）

BTW，你为什么在意呢？带标签的结构仍然代表模型，并且可以在持久层之外使用。你可能在尝试优化一些不被破坏的东西，而只是为了遵守规则pattern@Plato这是一个愚蠢的问题，因为映射必须发生在某个地方，而域模型是一个好地方这是我的整个思路，因为我对域模型中的bson.MongoID类型的id不满意，然后做得太过分了，思考得太清楚了。为帮助我澄清而干杯。