How can you document your domain model with ubiquitous language and domain-specific diagrams?

Before getting documented, ubiquitous language first needs to be spoken. Technical teams need to identify critical terms used by domain experts and repeat them back in their inquiries. Technical jargon apart from that should be replaced with actions describing what is done rather than how. E.g. "we will update the package tracking status every 20s" rather than "we will keep a thread running in the background, polling the tracking API every 20s". After this discipline is established, ubiquitous language should spread throughout documentation naturally.

I prefer quickly getting to a context map first and iterating on it until the domain experts are satisfied with the representation. Context maps are easy to sketch out and act as a great starting point for deeper architectural discovery. They can be discarded and redrawn in iteration with new understanding and discussion. Once the system is understood at this level, other diagrams with more detail can be created for individual bounded contexts or their interactions (e.g. if the system is built out of microservices). Context maps on paper can be photographed and pasted in knowledge portals, or created with tools such as ContextMapper. I prefer quick-and-dirty sketches in initial iterations, and then using ContextMapper when they mature.

Domain-Driven Design prefers less rigorous documentation and using code as the single-source of truth whenever possible. If the rich domain model approach is used and the domain code is properly separated from the rest (presentation, data, etc.), central parts of the code become easy to reason about and discuss between the tech and domain experts. If visual representation is still required, there are tools that can easily generate UML and other diagrams out of the domain model. The choice of diagrams depends on who the target audience is. The striving for keeping documentation lean stems from the fact that it easily gets outdated and misinformative in agile environments, since the implementation evolves much faster and is always ahead.

A system can be viewed from multiple perspectives. (e.g. 5 perspectives in the 4+1 architectural view model or 4 in the model proposed by iSAQB). For simplicity the domain model documentation can start with two views and be extended later on. The 2 views are static and process. A Domain Model can be nicely presented as Context-Diagram (UML) and Bounded-Context-Diagram (DDD). The process view of the domain can be visualised as BPMN, Use-Case-Diagram (UML) or as Event-Storming Context-Map.