Woah, Nellie.NET!

From my simple mind to… mine…

Notes from "DDD, Chapter 2: Communication and the User of Language"

leave a comment »

I’m rereading DDD by Evans for the San Antonio Tech Book Club. We’re taking it a chapter at a time. As is usual with this book, there is always more to learn every time I crack open this fairly dry, but useful tome.

The intro to Part 1 of the book defined terms such as DOMAIN, DOMAIN MODEL, and the need for the domain model. Chapter 1 discussed “Knowledge Crunching” – reworking the domain model to the essentials, changing the model based on learning, and deep models.

Chapter 2 is about the use of the UBIQUITOUS LANGUAGE (UL).

  • If the DOMAIN MODEL is the refined elements of the domain, as decided upon by business experts and developers, then the UBIQUITOUS LANGUAGE (UL) is the common language that is more robust than – but still based on – the model.
  • Schisms should not be allowed when using the UL. That is, different team members should not use terms in different ways from the agreed upon meaning. If so, a change in the model is required.
  • With no UL in place, or if schisms are allowed, then the need to translate between different uses of terms is significant. When the terms used in the code are different from those used in day-to-day language, then other aspects of modeling become troublesome (“makes knowledge crunching anemic”).
  • The UL consists of names of classes and methods, rules, organizing principles, model relationships.
  • The UL should be used by all team members to make it pervasive and thus ubiquitous. Team must be committed to this.
  • Model out loud. Use the UL in day-to-day speech.
  • Although the UL can consist of more than what is in the code, when something is identified as strange in the UL, then that concept/term should be corrected and propagated back to the DOMAIN MODEL.
  • The model derives from the domain expert’s language, but is refined. Domain experts should object if the meaning of something in the model diverges from the meaning accepted in the domain.
  • As with anything Agile, the UL should be constantly reworked as concepts are introduced or changed.
  • Multiple languages in the domain are allowed, but NEVER between the domain expert and developer. A language EXTENSION  is specialized jargon that is not used in the UL but has meaning to a certain party (developer or domain expert) to discuss an aspect of the system. See Figure 2.3 in the book.
  • A few pages of discussion on documentation. My take is to realize that 1) the UL will always be more dynamic than documentation, 2) you must be careful as to what concepts you decide to commit to paper since the moment you do, you have to maintain that documentation especially if the UL is always changing, and 3) the model is NOT just the diagram representation – any documentation beyond the code should complement the model. All other details should be captured in the code since it is the definitive representation of the agreed upon model.
  • Code must be based on the UL and DOMAIN MODEL to be useful. Developer should not say something in the UL and represent that concept differently in the code.
  • EXPLANATORY MODELS are models that are not related to code, but can be used for learning. They are often a different representation of the DOMAIN MODEL or EXTENSIONS.
  • BOTTOM LINE: The UBIQUITOUS LANGUAGE is important because it goes beyond a purposefully limited DOMAIN MODEL and acknowledges that the spoken language is more dynamic than code, diagrams and other forms of documentation.

Written by Nelson

December 1, 2008 at 9:21 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: