Often times developers are reluctant to hard code domain or relational constraints, because there are no written specifications formally defining what should be considered valid. How data is conformed, constraints, and exceptioned is definately something that needs to be documented upfront.
One common issue I see are VarChar "date" columns. What I sometimes do (when refactoring the column to Date type isn't an option) is place a check constraint on the varchar column. First it casts the value to Date type (which will throw an exception if the value isn't a real date), and then it compares the value to a YYYYMMDD formatted conversion of itself (which verifies the value conforms to this standard string format).
create table foo
foo_date varchar(30) not null
check (foo_date = convert(char(8),cast(foo_date as datetime),112))
insert into foo (foo_date) values ('2011/02/28');
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_foo_date_yyyymmdd".
insert into foo (foo_date) values ('20110229');
Msg 241, Level 16, State 1, Line 1
Conversion failed when converting date and/or time from character string.
insert into foo (foo_date) values ('20120229');
(1 row(s) affected
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho