You haven’t just moved the descriptive name from the variable name to the type.
If you are using a strongly typed language, you can just right click on the accountId type and find everywhere in your codebase where the “accountId” is being used.
The “accountId” is not “just an int”. An accountId has semantics that would be different than an int. An accountId is not the same as a “customerId” that may also be represented as an int. The accountId also has different uses than an int. You’re not going to take the sum, average, etc of an accountId.
An accountId that happens to have a value of 1 is semantically not equivalent of a customerId of 1. A method that expects a list of accountIds that are just ints will just as happily take a list of customerIds.
But a method that takes as a parameter List<AccountId> will cause a compile time error if you pass in a List<CustomerId>.
Why use a strongly typed language and then ruin one of the benefits of it if you don’t use domain specific types?
If you are using a strongly typed language, you can just right click on the accountId type and find everywhere in your codebase where the “accountId” is being used.
The “accountId” is not “just an int”. An accountId has semantics that would be different than an int. An accountId is not the same as a “customerId” that may also be represented as an int. The accountId also has different uses than an int. You’re not going to take the sum, average, etc of an accountId.
An accountId that happens to have a value of 1 is semantically not equivalent of a customerId of 1. A method that expects a list of accountIds that are just ints will just as happily take a list of customerIds.
But a method that takes as a parameter List<AccountId> will cause a compile time error if you pass in a List<CustomerId>.
Why use a strongly typed language and then ruin one of the benefits of it if you don’t use domain specific types?