Eric Evans' Domain Driven Design is the most interesting text on software design I have ever read and I'm only 27 pages in. I can finally reflect my work experiences in a design text and really contextualize the dysfunction I experience on a daily basis.
Yes, the principles of DDD lead to the horrors of "Enterprise" but in reality I think that the reason Enterprise OOP is in such a pitiful state is because few people in this space ever bother to internalize the _reason_ for designing software this way. They simply do what they see in established codebases without critically addressing it.
Understanding this contextualizes _why_ things like UML exist. UML is a meta-language to describe that domain language. Languages evolve. The way people apply UML as an upfront artifact of the dev process that rarely changes is antithetical to the purpose of modeling your domain in the first place.
The main takeway I've just taken is that, your code is both a product of and a definitive text describing the language you use to communicate the domain your software is built to work in. Therefore it _should_ reflect both the knowledge of experts in the field, and the expertise of the developers working on it.