Terry.Cho's blog

Leverage communication with DDD (Domain Driven Design) August 19, 2009

I am a consultant so now days I am looking at DDD (Domain Driven Design).

One of important point in architecture analysis and design is “How to extract requirements from customer? And How to visualize the requirement by using model?” Model itself is not an objective but a tool or method. It acts as common language between stake holders. And it helps us to communicate more effetely.

Another problem in project is communication. Sometimes stakeholders (Developer, Customer, Different biz team, Analysist, Architecture) in the project misunderstand same concept to different meaning.  It makes many problem and communication cost.

Common problem of these is that “Project members don’t understand Context”. It is communication problem. If all members in the project can share the context and understand same concept as same meaning. We can prevent problem from mis-communication.

DDD is started from this concept.  Basically it describes communication way between domain(business part) and programmer (IT part).  It also explains software design pattern etc. But I have a interest in communication and how to share context etc.

Let’s summarize concept with figure.

First step. Construct main model.

First step is ‘analysis target business’. Describe business scenario and flow by using some diagram. You can use any diagram that you want like UML, BPM or Use case. But it has to be effective and easy to understand for communicating between biz part and it part.

All of biz and it people have to use same language. We call it as “Ubiquitous language” in DDD. It is business(or domain) term not a technical term. For example “JMS Queue”, “XML Message” – this is technical term. “Account”, ”Transfer” – this is business term.

Use biz term for communication!!

Another important thing is “make glossary”. Term is always important and it always be a cause of miscommunication. Even if we are using same biz term. It sometimes can be different depends on organization or role. So we have to make “glossary” It is also useful when a new member join the project. We don’t have to explain term to him but just pass glossary. I suggest use glossary in wiki pages. It is always live and easy to search. (Don’t use Excel or word document for glossary. It is a tomb of document)

After making main model and glossary we can start communicate with same language and share context.

Second step. Separate main model.

Second step,  cut the main model to small pieces with details.
Project members have a interest in just what they have to do. Main model let us to share and understand context. Sub model let us know what individual people should do.

In DDD, it uses “Boundary Context” to cut the main model. The boundary can be organization or business function or unit etc. When cutting the main model if it has a dependency to other sub model, you should include the dependency in your sub model. It makes members to recognize dependency to other biz (or sub model) in your sub model.

When we cut the model, providing traceability between models is very important. Every sub model has a relationship to main model and other sub model with boundary, dependency etc. If we do not state the relationships, somebody can lose a context from sub model.

There are many ways to provide traceability like structured numbering (1. 1.1 1.1.1 etc). But numbering is not effective. Even if it can provide traceability , ratability is low . Diagram is more effective. DDD introduces “Context Map”. It looks like mind map. It describes model and relationships between the models.

Third step. Make common model from sub models.

After cutting main model to sub model. We can understand “What is whole system to do?” (by main model) and “What is my role and boundary in the system ?” (by sub model). “Whom I have to talk with and co-work with ?” (context map)

As I mentioned between sub model , there are relationships. It tells us it can have common module.

In third step, extract common module between sub models. DDD named this common module as “Shared Kernel”. DDD guides ownership of  the “shared kernel” is teams that related the shared kernel. But I think it is very hard. People always push their role to others. My suggestion is give a role of “shared kernel” to one team specifically. And if there is some concerns or issues between the teams, Architecture Team or Project Management Office intercede it.

Keep sharing Context

Even if we made model, sub model and context map. All of them are always changing. To catch up the changed context we have to share the context continuously. It is Continuous Integration (CI). CI term is used for automated build and test automation. But in this article CI is like a review meeting. Periodically review model with stakeholders and  share the context. It let us to keep same contexts.

Conclusion

DDD describes about communication model and traditional software design patterns (like Gof’s design patterns) But the design patterns are already introduced by many other documents and books. I want to emphasize communication and modeling ways in DDD. Main model, Sub Model with boundary context, Context map and CI is very nice way to communication and context sharing