4 ms·

>Even the IDs of his aggregates were classes. People were arguing for such a thing because e.g if you have 2 guids then you can write code which handles two c

>Even the IDs of his aggregates were classes. People were arguing for such a thing because e.g if you have 2 guids then you can write code which handles two completely unrelated guids like `student.Id == car.Id` meanwhile if you have types like StudentId and CarId then you'd have compilation error While I'm not a fan of this, then the concept is sound.

0xCAP 3y ago
Yes, this is a philosophical issue that lies within our attempts to model reality in our systems. What defines identity? A dog named Brian is not the same as a man named Brian. For value objects, surely Leibniz's philosophy applies: if a theory describes two situations as being distinct, and yet also implies that there is no conceivable way, empirically, to tell them apart, then that theory contains some superfluous and arbitrary elements that ought to be removed. For entities, it's much more complex. I still feel some kind of way when seeing classes (with methods!) being used for IDs, though.
- tcfhgj 3y ago
  > still feel some kind of way when seeing classes (with methods!) being used for IDs, though. Depends on the language. In many languages strings are classes in general, so it makes sense that a new type for a strong is is one as well
- Mawr 3y ago
  I've no clue what you just said :) Modeling the business domain with types that match it is table stakes. Otherwise you end up with a "stringly-typed" codebase in which everything is just a primitive type. This and the issues the author of the article is facing comes from the wrong mindset. Your job is not to create the purest, most perfect codebase, but to deliver value to your users. Code is a means to an end.
  - runald 3y ago
    > I've no clue what you just said :) This. Before you wax all philosophical, try to understand first what you are arguing for and against. Make sure to read what you wrote at least two times, and that it actually makes any sense.
Seb-C 3y ago
I have done that in Go and Typescript ("branded types"), it's actually very useful to discriminate ids. It prevents stupid mistakes that are actually hard to spot. Making it a whole class is maybe going too far however, as the costs may outweight the benefits.
- esafak 3y ago
  nim has distinct types, kotlin has inline classes, scala has type aliases. It is a good feature.

0xCAP 3y ago

Yes, this is a philosophical issue that lies within our attempts to model reality in our systems. What defines identity? A dog named Brian is not the same as a man named Brian. For value objects, surely Leibniz's philosophy applies: if a theory describes two situations as being distinct, and yet also implies that there is no conceivable way, empirically, to tell them apart, then that theory contains some superfluous and arbitrary elements that ought to be removed. For entities, it's much more complex. I still feel some kind of way when seeing classes (with methods!) being used for IDs, though.

tcfhgj 3y ago
> still feel some kind of way when seeing classes (with methods!) being used for IDs, though. Depends on the language. In many languages strings are classes in general, so it makes sense that a new type for a strong is is one as well
Mawr 3y ago
I've no clue what you just said :) Modeling the business domain with types that match it is table stakes. Otherwise you end up with a "stringly-typed" codebase in which everything is just a primitive type. This and the issues the author of the article is facing comes from the wrong mindset. Your job is not to create the purest, most perfect codebase, but to deliver value to your users. Code is a means to an end.
- runald 3y ago
  > I've no clue what you just said :) This. Before you wax all philosophical, try to understand first what you are arguing for and against. Make sure to read what you wrote at least two times, and that it actually makes any sense.

Seb-C 3y ago

I have done that in Go and Typescript ("branded types"), it's actually very useful to discriminate ids. It prevents stupid mistakes that are actually hard to spot. Making it a whole class is maybe going too far however, as the costs may outweight the benefits.

esafak 3y ago
nim has distinct types, kotlin has inline classes, scala has type aliases. It is a good feature.