域驱动设计自动递增实体密钥
刚开始使用域驱动设计，我了解到您应该将模型保持在有效状态，并且在创建类的新实例时，建议将所有必需的属性作为构造函数参数。
但是，当使用自动递增的键时，当我从持久层调用Add方法时，我只有这个新ID。如果我在没有密钥的情况下实例化对象，我认为它们将处于无效状态，因为它们需要某种唯一标识符。
我应该如何实现我的架构，以便在创建我的实体的新实例之前拥有我的id？
共有2个答案
对Dmi的评论表示赞同
1）您可以在工厂方法中确保您的实体存储到数据库中。这可能适用于也可能不适用于您的域，但如果您确定要保存该实体，这可能是一种有效的方法
2） 您可以从数据库中将ID与主键分开。我曾经处理过一个案例，如果客户付款了，那么只有一个订单，并且在这一点上，它将通过它的发票id（一个后续id）来识别。这并不意味着在数据库中我需要一个列ID，它也是对象的主键。您可以在数据库中有一个主键（随机guid），直到有一个ID（int？）如果它还没有被填充，则为sequentual和null。
这里的实用方法是使用随机ID并在实例化实体之前生成它们，例如在工厂中。GUID是一种常见的选择。
在你问之前：不，你不会用完 GUID ：-）
如果出于某种原因必须使用顺序 ID，则仍然可以选择：
- 查询DB上的序列以获得下一个ID。这取决于您的DB产品，例如Oracle有它们）
- 创建一个具有自动递增键的表，该键仅用作键保留表。要获取ID，请在该表中插入一行-生成的键现在为您保留，因此您可以将其用作实体的ID
注意，这两种顺序ID的方法都需要在开始创建实体之前进行DB往返。这就是为什么随机ID通常更简单的原因。因此，如果可以，请使用随机ID。
另一种可能性是，您只是忍受这样一个事实，即您在创建时没有 ID，但只有在数据库上的插入操作成功时。根据我的经验，这使得实体创建使用起来很尴尬，所以我避免使用它。但对于非常简单的情况，这可能是一种有效的方法。
-
我正在阅读领域驱动设计中的存储库和Microsoft微服务架构模式，他们都同意我应该为每个聚合根拥有一个存储库。我大体上同意这一点，但我有一个命名问题。 聚合是存储库作为... 实体是？？？ 值是？？？ 在我的特定场景中，我有一个营销网站上下文中产品对象的存储库。 Product是ProductInfo营销信息实体（Aggregate Root）、ProductSpec和ShippingInfo实
-
我正在学习DDD概念，为了加强我的理解，我正在研究一些现实世界的例子。 我知道一个聚合应该只有一个通过根实体的入口点，一个聚合应该只有一个存储库(如果我完全理解错了，请纠正我) 现在假设有特定类型的消耗品，并且这些消耗品是从配送中心发送的。发送特定类型的消耗品取决于它们的数量，我的意思是，如果其中一个消费者对A型和B型的临界数量为10，并且这些项目的数量低于10，那么配送中心发送A型和B型消耗品。
-
本文向大家介绍谈一下领域驱动设计相关面试题，主要包含被问及谈一下领域驱动设计时的应答技巧和注意事项，需要的朋友参考一下 主要关注核心领域逻辑。基于领域的模型检测复杂设计。这涉及与公司层面领域方面的专家定期合作，以解决与领域相关的问题并改进应用程序的模型。在回答这个微服务面试问题时，您还需要提及DDD的核心基础知识。他们是： DDD主要关注领域逻辑和领域本身。 复杂的设计完全基于领域的模型。 为了改
-
问题内容： 我的架构看起来像这样： 我已经在同一数据库中创建了counters集合，并添加了一个带有’entityId’的_id的页面。从这里我不确定如何使用猫鼬来更新该页面并获取递增编号。 没有计数器的架构，我希望它保持这种状态，因为这实际上不是应用程序使用的实体。仅应在模式中使用它来自动递增字段。 问题答案： 这是一个示例，如何在Mongoose中实现自动增量字段：
-
本文向大家介绍什么是领域驱动设计（DDD）相关面试题，主要包含被问及什么是领域驱动设计（DDD）时的应答技巧和注意事项，需要的朋友参考一下 专注于核心领域逻辑 在模型上找到综合的设计 不断与领域专家合作，改进应用程序模型并解决与领域相关的问题
-
本文向大家介绍为什么需要域驱动设计（DDD）？相关面试题，主要包含被问及为什么需要域驱动设计（DDD）？时的应答技巧和注意事项，需要的朋友参考一下 映射领域 降低复杂性 可测试性 可维护性 知识丰富的设计 将业务和服务结合在一起 上下文集中 通用语言