模型名称通常是某个实体的单数名称。表名是单词的复数形式。
例如，Transaction存储在transactions表中。
但是有些情况是整个表格用单数词来描述，意味着实体的范围。例如：日志，日志，历史。
除了＆＃34; entry＆＃34;之外，没有更精确的单行名称。或＆＃34; item＆＃34;。但是名为ThingsJounralEntry的模型看起来很混乱，简单的ThingsJournal令人困惑，因为实例并没有描述任何实际的日记，而是单一条目。
对于此类案例，是否有比上述更好的通用命名方法？
答案 0 :(得分：0)
你的问题似乎表明舞蹈中实际上存在两个命名问题。一个是关于你的集合的元素，你明确要求。另一个是关于集合本身，这是隐含的。事实上，当你提到Journal时，你感到被迫澄清（会计）。这意味着您的集合类将更好地命名为AccountingJournal,，这将消除歧义。
现在，由于您提供的这些对象（集合和元素）的描述有点简洁，我没有足够的信息来建议适当的名称。但是，为了给你一些提示，我建议不仅要考虑元素的性质，还要考虑它们在模型中的责任。他们会代表实体或行动吗？如果元素是实体（事物），则考虑名称，这些名称表示将复制或熟悉会计师使用的语言的简单名词。示例包括AccountingEntry或AccountingRecord.如果您的元素代表操作，则使用强调此类特征的后缀，例如AccountingAnnotation或AccountingRegistration.您可以问自己的另一个问题是什么样的这些元素将收到的消息？例如，如果它们代表货币的增加和减少，您可能希望使用AccountingOperation或AccountChange.
无论域名指定的情况如何，您都应该验证您的命名约定听起来像实际领域专家所说的句子：“[这是] [某事]的会计记录”或“将此会计记录添加到期刊”或“在日记帐中注册这种会计操作”甚至“这是减去这笔钱的会计操作”，等等。
命名对象的（知识）活动与塑造模型的活动直接相关。通过大声说出他们通常会收到的信息并检查您正在塑造的语言是否会重现域的语言来锻炼您的预期模型。换句话说，让你的对象说话并听到他们说的话，他们会告诉你他们的名字。