Good post. The technical patterns are nigh useless unless you're going all in on event sourcing and/or CQRS - and perhaps even then. KISS > DDD.
To me, what matters are the strategic patterns, i.e. how you think and talk about your domain. What a lot of (microservice) software gets wrong is bounded contexts and APIs, which can be improved through event storming (discussing what kind of things happen in your domain) and context mapping (how that [sub]domain interacts with others). And then there's ubiquitous language, or calling the thing what it is to the business, not some programmer gobbledygook.
I'm an Argentine Spanish-English bilingual programmer. I try to program exclusively in English, but when developing integrations to Argentine systems I often have to fall back to spanglish code.
In general it's preferable to use only english because the code is more readable (because the language's keywords and APIs are in english), but also to maintain consistency with noun-adjective order, verb tenses, etc. Some local concepts can be easily translated (or at least it would seem so) like invoice-factura ... but then inevitably I arrive at concepts for which there is no obvious translation (so I could make one up, but it would not be clear enough for others) or for which the translation doesn't exactly line up.
I think this is common all around the world. For example, the more my teams get close to money and regulations the more we have to use words of our own language. It would be pointless trying to invent a translation of very precise legal words for concepts that exist only in our own country.
To me, what matters are the strategic patterns, i.e. how you think and talk about your domain. What a lot of (microservice) software gets wrong is bounded contexts and APIs, which can be improved through event storming (discussing what kind of things happen in your domain) and context mapping (how that [sub]domain interacts with others). And then there's ubiquitous language, or calling the thing what it is to the business, not some programmer gobbledygook.