3 added 373 characters in body
source | link

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Is it "normal" to model the GUID as a string or should I be modelling it as a GUID in the model and database?

I don't think it matters very much. For most of your domain model, it is an identifier; the only query you ask of it is whether or not it is the same as some other identifier. Your domain model won't normally be looking at the in memory representation of an identifier.

If GUID is available as a "primitive type" in your domain agnostic setting, I would use it; it allows the supporting context to choose appropriate optimizations that may be available.

What you should recognize, however, is that the representation of the identifier, both in memory and in storage, is a decision you are making in your implementation, and therefore you should be taking steps to ensure that the foot print of code coupled to that decision is small -- see Parnas 1972.

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Is it "normal" to model the GUID as a string or should I be modelling it as a GUID in the model and database?

I don't think it matters very much. For most of your domain model, it is an identifier; the only query you ask of it is whether or not it is the same as some other identifier. Your domain model won't normally be looking at the in memory representation of an identifier.

If GUID is available as a "primitive type" in your domain agnostic setting, I would use it; it allows the supporting context to choose appropriate optimizations that may be available.

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Is it "normal" to model the GUID as a string or should I be modelling it as a GUID in the model and database?

I don't think it matters very much. For most of your domain model, it is an identifier; the only query you ask of it is whether or not it is the same as some other identifier. Your domain model won't normally be looking at the in memory representation of an identifier.

If GUID is available as a "primitive type" in your domain agnostic setting, I would use it; it allows the supporting context to choose appropriate optimizations that may be available.

What you should recognize, however, is that the representation of the identifier, both in memory and in storage, is a decision you are making in your implementation, and therefore you should be taking steps to ensure that the foot print of code coupled to that decision is small -- see Parnas 1972.

2 added 580 characters in body
source | link

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Is it "normal" to model the GUID as a string or should I be modelling it as a GUID in the model and database?

I don't think it matters very much. For most of your domain model, it is an identifier; the only query you ask of it is whether or not it is the same as some other identifier. Your domain model won't normally be looking at the in memory representation of an identifier.

If GUID is available as a "primitive type" in your domain agnostic setting, I would use it; it allows the supporting context to choose appropriate optimizations that may be available.

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122

Is it "normal" to model the GUID as a string or should I be modelling it as a GUID in the model and database?

I don't think it matters very much. For most of your domain model, it is an identifier; the only query you ask of it is whether or not it is the same as some other identifier. Your domain model won't normally be looking at the in memory representation of an identifier.

If GUID is available as a "primitive type" in your domain agnostic setting, I would use it; it allows the supporting context to choose appropriate optimizations that may be available.

1
source | link

Will this always be unique?

Always? no, not always; it's a finite sequence of bits.

Say I had a database containing millions and millions of rows with a GUID as the Primary Key.

Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out of disk space by the time that happens.

Can I just do this?

You can; it's not a wholly good idea. Your domain model shouldn't normally be generating random numbers; they should be inputs to your model.

Beyond that, when you are dealing with an unreliable network, where you might get duplicate messages, a deterministically generated UUID will protect you from having duplicate entities. But if you assign a new random number to each, then you have more work to do to identify the duplication.

See the description of name-based uuid in RFC 4122