Equality for a DateOfBirth Value Object
'fit for purpose' depends on what exactly that purpose is. Do you want to register the time of birth (as the Value property suggests), or only the date (as the class name seems to imply)? Does it need to handle birth dates before 0 A.D.? Does it need to reject non-existing dates (depending on actual historical data)?
If this class is meant to store a date only (not a time component), then it makes more sense to give it Year, Month and Day properties, rather than a Value property that exposes a time component.
DateTime.MinValue is the default value of DateTime, but why does that make it an invalid birth-date?
It may be useful to provide (explicit or implicit) conversions operators from and to DateTime, and perhaps parsing methods, depending on where and how this class is meant to be used. However...
...the purpose of this class seems very narrow. Judging from your other posts, you are thinking about creating many such 'value' types? That's a lot of work (at least in C#), but what problem does it solve? Where's the added value? Are you worried that someone may accidentally assign an expiry-date to a birth-date field? Remember, all that extra code needs to be maintained, and there's a cost associated with that.


My impression is that yes, you are over-engineering this. I suspect that you'll find more value in writing automated tests (which, when done properly, should have caught that &gt;= operator bug, and should catch expiry-date/birth-date mixups just as well) than in adding this sort of complexity. C# requires too much boiler-plate to make this approach viable, so unless lives are at stake I wouldn't bother.



EDIT: A few more notes:


In C# 7, ReferenceEquals(a, null) can be written more succinctly as a is null.
The null check in CompareTo uses the overloaded != operator, but you might as well use a reference check directly.
Why are the Equals methods not using Comparison? The same goes for the != operator: why doesn't it do Comparison(dateOfBirth1, dateOfBirth2) != 0?