In the area of health (a beautiful example of complex systems) we use a "Ubiquitous language" to describe models through the language ADL (Archetype Description Language). This language is defined by the openEHR standard, which offers various tools for documentation and discussion of models among domain experts.
This is specific to the area of health, but I believe to be an excellent model for what you are wanting.
You can find material on language specification and models under development at http://www.openehr.org/pt/home
You will also find the models under development in http://ckm.openehr.org/ckm/
I’m no expert on Eric Evans' theories, but I believe there’s a lot of adherence to what was proposed by Sam Heard and Thomas Beale.
Here’s a short article I wrote about archetypal development:
Methodological Proposal for the Development of Archetypes
Abs
I find it very strange to document the ubiquitous language. It is born from the jargon of business, it is the language that must be understood and spoken by everyone in the project, including by code, and it always evolves. I did not understand as a document with the sole purpose of describing the ubiquitous language could help not create duplicated resources in the project. Could explain further your problem or goal?
– Caffé
It is true that everyone should understand and speak the language of the project, so far so good, but for example, focusing on the code, a new developer arrives and will develop something related to sale. How is sale defined in this project?
boleto
,pedido
,comanda de venda
,orçamento
? What documentation should he consult in this situation? Or should he talk to someone in the project?– rubStackOverflow
He’s already talked to someone on the project, or he wouldn’t have gotten work to do. Even if he has only read the text of a requirement without talking to anyone, if the person who wrote the requirement used the ubiquitous language, in requirement is written "change blah blah blah on sale", then he will easily find the code he needs, because he will look for "blah-blah-blah" inside "sale", and will not waste time looking at the code of "billet" or "request" because the requirement that bothered to use ubiquitous language mentioned only the correct and relevant terms of business.
– Caffé
See: ubiquitous language must be spoken by everyone in the project, including code must speak the ubiquitous language.
– Caffé
Then the project documentation (discussed/documented, etc.), including code, in a project that applies DDD would be sufficient in this case?
– rubStackOverflow
That! And this is the wonder of the D.O.D.: after having a conversation using just a frame and a pen, without having to turn on any computer, the new team member is already able to find himself in the source code and work on the project. You don’t talk about code, you talk about architecture, design and business.
– Caffé