使用自然键作为DomainObject的ID或GUID +自动增量域驱动设计 [英] using Natural key as the ID of DomainObject or GUID + auto-increment Domain Driven Design
问题描述
我一直在阅读很多关于DDD的文章，并注意到，大多数文章使用GUID作为数据库持久化时的ID。他们说，GUID缩小，自动递增ID在扩展性方面是一个很大的no-no。
I've been reading a lot of articles about DDD and noticed that most are using GUID as their ID when persisting to a database. They say that GUID scales well and auto incrementing ID's are a big no-no when it comes to scalability.
我现在很困惑是否使用 GUID 或自动递增。
Im confused now whether to use GUID or auto-increment.
基本上，域名是会员制（二进制树）。 （跟踪注册会员）
第一个要求是我们应该在系统中唯一标识它们的东西（我们称之为code>帐号No。）也许是7digit。
The first requirement is that we should have something that uniquely identifies them in the system (we call it Account No.) perhaps 7digit.
然后新的会员由另一个会员注册。我们称之为推荐。
Then new Members can be registered by another Member. We call it referral.
现在我计划做的是将GUID类型的 MemberId 作为DomainObject Id其中它作为将用于联接的主键，外键（在Referral，referer_id将是GUID MemberId ）。 AccountNo 将是一个自动增量列，或者它将从存储库（MAX（）+ 1）获取。主要用于系统和链接中的搜索功能
Now what Im planning to do is to have MemberId of GUID type as the DomainObject Id where it serves as the primary key which will be used for joins, foreign keys (on Referral, referer_id would be the GUID MemberId). AccountNo will be an auto-increment column or maybe it will be acquired from repository by MAX() + 1. Mainly it will be used for search features in the system and in links.
如果DomainObject的ID仅仅是技术实现，对于系统的用户是否保持隐藏？
Should the ID of DomainObject remain hidden to users of the system since its just a technical implementation?
结合两者可以吗？ GUID作为row_id在数据库（代理键）。和自然增量（自然键）？
Is it ok to combine both? GUID as row_id in database (Surrogate Key). and Auto-Increment for (Natural Key)?
是否可以从构造函数中排除 AccountNo ，因为它会自动增加吗？需要执行不变量？那么从存储库获取下一个ID，并在构造函数中包含 AccountNo ？
Is it okay to exclude the AccountNo from the constructor because it will be auto-incremented anyway? What about the need to enforce invariants? So is getting the next ID from repository the way to go and include AccountNo in the constructor?
我应该只是坚持使用自动递增ID，并忘记GUID，删除 MemberId 并让 AccountNo 成为DomainObject的ID？
Should I just stick with Auto-Increment ID and forget about GUID, remove MemberId and let the AccountNo be the ID of the DomainObject?
注意：
我没有建立下一个Facebook。
I am not building the next facebook of some kind.
我只想练习DDD的战略方面，学习如何做出坚定的架构决策，知道他们的PROS和CONS及其实现。
I just want to practice the Strategic side of DDD to learn how to make hard architectural decisions knowing their PROS and CONS and their implementation.
如果我们将会员注册的3种情况：
If we will make 3 scenarios with member registration:
- 第一种情况：会员注册每分钟发生一次。
- 第二种情况会员注册每小时发生一次。
- 第三种情况：会员注册每天最多5次。
如何影响决策？
技术栈：
- ASP MVC 5
- Sql Server 2014
- C＃
- Dapper ORM
- ASP MVC 5
- Sql Server 2014
- C#
- Dapper ORM
- 全局标识符
- 可以从应用程序轻松生成。自动递增的id意味着复杂的服务或对数据库的依赖。不要使你的生活复杂化。
推荐答案
我只想练习DDD的战术方面，学习如何使硬建筑决策知道他们PROS和CONS。
I just want to practice the Tactical side of DDD to learn how to make hard architectural decisions knowing their PROS and CONS.
你错了。你不能通过做策略学习策略。战术是实施策略的方法。但是你需要一个策略。
You got that wrong. You can't learn strategy by doing tactics. Tactics are ways to implement a strategy. But you need a strategy first.
无论如何，你的问题很简单：使用Guid。它有两个优点
Anyway about your question, it's quite simple: use a Guid. It has 2 advantages
自然ID，如AccountNo也应该被使用。然而，Guid是技术目的。自然键格式可能会在将来发生变化，Guid可以轻松支持自然键多种格式。
The natural id, like AccountNo, should be used too. However, the Guid is there for technical purposes. The natural keys format might change in the future, the Guid makes it easy to support natural key multiple formats.
作为一种做法，最好是将您的实体ID设为值对象（即使它只是Guid）。您也可以在 AccountNo 中加入guid，VO不需要只有一个值。例如，在我目前的应用程序中，我有一个 ProjectId（Guid organization，Guid idValue）和 ProjectAssetId（Guid organization，Guid projectId，Guid idValue） 。
As a practice, is best that your entity id to be a value object (even if it's just Guid). You can incorporate the guid in AccountNo too, a VO doesn't need to be only one value. For example, in my current app, I have a ProjectId(Guid organization,Guid idValue) and ProjectAssetId(Guid organization,Guid projectId,Guid idValue).
这篇关于使用自然键作为DomainObject的ID或GUID +自动增量域驱动设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
