using Natural key as the ID of DomainObject or GUID + auto-increment Domain Driven Design

Question

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.

Im confused now whether to use GUID or auto-increment.

Basically the Domain is about membership system (binary tree). (tracking of register members)

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.

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.

Should the ID of DomainObject remain hidden to users of the system since its just a technical implementation?

Is it ok to combine both? GUID as row_id in database (Surrogate Key). and Auto-Increment for (Natural Key)?

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?

Should I just stick with Auto-Increment ID and forget about GUID, remove MemberId and let the AccountNo be the ID of the DomainObject?

NOTE:

I am not building the next facebook of some kind.

I just want to practice the Tactical side of DDD to learn how to make hard architectural decisions knowing their PROS and 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.

If we will make 3 scenarios with member registration:

• First Scenario: Member registration happens every minute.
• Second Scenario: Member registration happens every hour.
• Third Scenario: Member registration happens atmost 5 daily.

How will it affect the decisions?

Technology Stack:

• ASP MVC 5
• Sql Server 2014
• C#
• Dapper ORM

Answer 1

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.

Anyway about your question, it's quite simple: use a Guid. It has 2 advantages

1. global identifier
2. can be generated easily from the app. An auto incremented id means a complicated service or reliance on the db. Don't complicate your life.

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.

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).