ddd-forum
ddd-forum copied to clipboard
[Question]: userId property in User class (also postId in Post etc.)
A few questions basically:
- What is the purpose of the userId/postId properties when there is already one called id in the AggregateRoot class? Especially since they are initialized with the same value.
- Why is UserId an Entity?
- Why does its create static method return a Result even though it will always be a success?
-
Making the implicit explicit. Making the differentiation between a
PostIdand anIdin general. I can lean on it not being entirely necessary. If we just used theUniqueIdentifieras a type instead, that'd make things a lot simpler, but it does help type-checking so that we don't mix types. I'll think about it, but really - either way is fine. -
It shouldn't be. Allow me to fix that in a PR. They should be value objects.
-
Some code is missing here. We need to do null-checking.
Here's an example of what (3) might look like.
import { UniqueEntityID } from "../../../shared/domain/UniqueEntityID";
import { Result } from "../../../shared/core/Result";
import { ValueObject } from "../../../shared/domain/ValueObject";
import { Guard } from "../../../shared/core/Guard";
export class PostId extends ValueObject<{ value: UniqueEntityID }> {
getValue (): UniqueEntityID {
return this.props.value;
}
private constructor (value: UniqueEntityID) {
super({ value });
}
public static create (value: UniqueEntityID): Result<PostId> {
let guardResult = Guard.againstNullOrUndefined(value, 'value');
if (guardResult.isFailure) {
return Result.fail<PostId>(guardResult.getErrorValue())
}
return Result.ok<PostId>(new PostId(value));
}
}
Does that help at all? Any other questions?
-
- makes sense
-
- makes very much sense
-
- Originally, when PostId was a subclass of Entity this didn't make sense because if you pass null to the constructor you get a new uuid() value. This way it makes more sense, although, isn't it enough that the create function method requires a non-null value?
@vprenner I thought about it, and you're definitely right. Walking through the logic, it could greatly simplify things to just fall back to using UniqueIdentifier for the ids. Great call. I'll throw up a PR and refactor this. Thank you!