Constructor validation is great, but it’s hard to tell from this example whether Book is meant to be a domain object (POJO) or a transfer object (JavaBean). It

Constructor validation is great, but it’s hard to tell from this example whether Book is meant to be a domain object (POJO) or a transfer object (JavaBean). It _looks_ like a transfer object (since CRUD was mentioned), but it’s unclear. Either way, a more appropriate solution might be to stop using “stringly” types and use Value Objects for the properties on Book. For example, “genre” should be either an Enum or some limited-value choice (perhaps from a database or external service). “Title” should be a Value Object class that constraints it to be of a certain length (at least 1 character). “Author” should be another limited-value choice (at least of type FullName, that has validity constraints). And “pageCount” should be a class that ensures it’s always >=1 (or maybe >=0 if that makes sense) and isn’t some outrageous value (granted, there’s always going to be some outlier that has an eBook that’s literally billions of pages, but that’s a biz decision that would be encoded in the PageCount class). Using types instead of Strings would prevent confusion/mistakes by other users, and push the validation to the exact type, instead of making Book do all the work.