DDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them.
No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems.
In highly regulated industries like banking or other highly-secure environments, it’s a gradient between an internal wiki or FAQs etc, to what you have as an example of something more expansive and explicit, to an entire book, to an entire department or business unit for more important concepts that may vary between jurisdictions or be less explicitly defined, but no less important or impactful to the running of the business or group.
No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems.
This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-...