Is there a model to document the "Ubiquitous language" in the DDD?

Asked

Viewed 466 times

6

I would like to know if there is a model to be followed for documentation of linguagem ubíqua or Ubiquitous language DDD. (ubiquitous language)

Explaining better, it would be something that would facilitate the search for some resource in the project, thus avoiding fragmentation or creation of duplicate resources.

I hope you’re not talking nonsense because I’m new in the area.

ddd software-project
  • 1

    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?

  • 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?

  • 1

    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.

  • 1

    See: ubiquitous language must be spoken by everyone in the project, including code must speak the ubiquitous language.

  • Then the project documentation (discussed/documented, etc.), including code, in a project that applies DDD would be sufficient in this case?

  • 1

    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.

Show 1 more comment

2 answers

3

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

inserir a descrição da imagem aqui

Abs

1


In the book Implementing Domain-Driven Design - Vaughn Vernon he suggests as an experiment for documenting the ubiquitous language the following:

  1. Draw images from the physical and conceptual domain and label them with names and actions. These drawings are mostly informal, but may contain some aspects of formal software modeling.
    Even if your team works with a formal model such as Unified Modeling Language (UML), you should avoid any type of ritual that triggers discussions and stifles the creativity of the final language being sought.
  2. Create a glossary of terms with simple definitions. List alternative terms, including those that are promising, those that are not, and why. As you include definitions, you may not help, but develop reusable phrases for the Language because you are forced to write in the domain language.
  3. Even if you don’t like the idea of a glossary, you can still capture some kind of documentation with important software concepts. Once again, the goal here is to bring up additional terms and phrases that are important to the domain language.
  4. Since only one or a few team members can capture the Glossary or other written documents, the rest of the team should review the resulting sentences. Not always, if ever, will there be consensus with the captured linguistics, so agility and heavy fixes are expected.

These are basic ideals with first steps to shape a language ubiquitous that fits into your domain. However, this absolutely not the model you are developing. It’s just the beginning of the ubiquitous language to be expressed in source code of your system.

Browser other questions tagged ddd software-project

You are not signed in. Login or sign up in order to post.