SteveDunn
Added a "well-known" SSN class to a new Vogen.WellKnown namespace
This Social Security Number (SSN) class is the first of a small series of "well-known" ValueObject classes I'd like to submit. Assuming the basic idea is workable, I'd be happy to submit a small series of similar classes; for instance:
UsPhoneNumber IsoCountryCode ZipCode CanadianPostalCode
Please note that the SSN class has been initially placed under a "WellKnown" folder / namespace in the main Vogen project. This probably wont be ideal, but I thought it'd do for a start.
ZipCode differs from country to country, and so does SSN. The SSN I use for example has 11 digits (6+5), and if this were to be added I'd have to specify global using SSN = ... etc..
IsoCountryCode and things that are 100% a standard I'm not necessarily opposed to, but anything that could possibly differ from one team to another should not be a part of the standard library.
The US-specific ones could be a part of Vogen.Standard.US or something along those lines. That would be good for another reason; Not being limited in what you can add to them; StateCodes, CountyCodes etc.. (I assume those are things in the US) would make sense there, but would absolutely make no sense in the standard library
These are interesting concepts and it would be nice to have a central (searchable) repository. There's probably such a central repository for regexes, which I think is one layer below what we're talking about here.
Maybe we could have a website, backed by a github repository, that allows users to search and select their 'domain concepts', and then have a 'Generate types' button that they can then copy/paste into their apps. I think space/separation wise, this would make sense, as I could imagine in years to come that there'd be thousands of types and it'd become difficult to dermine the granularity and area(s) of each domain concept.
Thank you again for your PR. I think this is a very interesting concept.
However, in its current form, I think we would end up with assemblies with dozens/hundreds of types of which users may want just one or two. This extra overhead is especially relevant because these types are generated on every build (and potentially analysed on every keypress)
I can see it working better in a scenario where a user goes to a website and searches for the types they are interested in. Kind of like a shopping cart for well known domain concepts. When 'checking out', the user will then either get the code for the definitions of those types, or even maybe a generated NuGet package.