docs

docs/why.md

@@ -51,12 +51,15 @@ As such, it is a capable complement to class building libraries like *attrs* (or
 
 However, as convenient as it might be, using it for your business or data layer [is problematic in several ways](https://threeofwands.com/why-i-use-attrs-instead-of-pydantic/):
 Is it really necessary to re-validate all your objects while reading them from a trusted database?
+Should the shape of your web API really apply design pressure on your business objects and therefore business code?
+
 In the parlance of [*Form, Command, and Model Validation*](https://verraes.net/2015/02/form-command-model-validation/), Pydantic is the right tool for *Commands*.
 
 [*Separation of concerns*](https://en.wikipedia.org/wiki/Separation_of_concerns) feels tedious at times, but it's one of those things that you get to appreciate once you've shot your own foot often enough and seen the results of allowing design pressure from the edges of your system, like ORMs or web APIs.
 
 *attrs* emphatically does **not** try to be a validation library, but a toolkit to write well-behaved classes like you would write yourself.
 If you'd like a powerful library for structuring, unstructuring, and validating data, have a look at [*cattrs*](https://catt.rs/) which is an official member of the *attrs* family.
+One of it's core tenants is that it doesn't couple your classes to external factors.
 
 
 ## … namedtuples?