领域建模命名问题答案

【问题标题】：domain modeling naming problem领域建模命名问题
【发布时间】：2011-02-26 16:16:13
【问题描述】：

应用程序中有一些简单的实体（例如，仅包含 id 和 title）很少更改，并且被应用程序中更复杂的实体引用。这些通常是Country、City、Language 等实体。

这些怎么称呼？我过去曾使用过以下名称，但我不确定哪个是最好的称呼方式：

谢谢

【问题讨论】：

【解决方案1】：

您标记为“ddd”，因此假设您正在寻找一种更受领域驱动的设计方法，请将标识符放在这些对象上并将它们视为Value Objects。

您可能考虑删除标识符的原因是它给问题域增加了不必要的复杂性。例如，我假设您的实现中有一个“国家”表？你仍然会拥有它，但它不会是参考查找。您将其纯粹用作“参考数据”。在需要引用的情况下预先加载它 - 例如，您的 UI 可能会将其绑定到下拉列表...

当实体被保存或更新时，您存储对象的值，因此“值”“对象”。如果用户将实体更改为另一个值，没问题，只需更新该值。这是在执行 CRUD 操作时必须进行的一种关联性较低的查找，这使得整个模型不那么复杂。

【讨论】：

谢谢。是的，我在 amzn.com/0321125215 中阅读了有关值对象的内容。这是一个有趣的概念，但在 db 级别它看起来不像非规范化吗？国家文字将散布在各处。更重要的是，当我需要更改国家/地区文本（例如拼写错误）时，我必须扫描许多表格才能应用修复。
@cherouvim - DDD 的关键之一是，只要您在实体和数据之间有可靠的映射层，数据库的外观就无关紧要。至于错别字，你是对的。您必须查看多个地方才能进行修复。不过，从管理方面来看，您始终可以维护一个存储过程来更新它的每个实例。例如，您可以有一个存储的过程来更新您的所有国家/地区引用，它以旧值和新值作为参数并为您执行更新语句，因此您只需调用一个过程来修复它。
（续）但可以说，必须更改现有值确实是一种极端情况。您需要执行此操作的频率非常低，并且由于这些数据是相当静态的，因此您应该在代码变为“生产质量”之前解决这些问题。您参考的书是“蓝色圣经”-我提供的链接上的定义来自同一个地方。 :-)
有道理，感谢您的数据。不过，存储过程对我来说是个亮点。

【解决方案2】：

我会说参考数据

【讨论】：