Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Thursday, May 21, 2009

Domain Models (continued)

Throughout my life as a software engineer I have participated in many different projects in various domains. Needless to say, I encountered some deja vu experiences in those projects, also known as war stories. One remarkable example always has been the problem domain itself. Even in projects with lots of experienced participants the problem domain had been often root of misunderstandings and misconceptions.  In large projects with outsourcing partners, external partners and other suppliers common knowledge of the problem domain is essential. A project  with lack of problem domain knowledge among the stakeholders is doomed to fail. Remember the tower of babel where lack of communication and insufficient common understanding lead to lethal catastrophe.

As I am mostly acting as software architecture mentor and coach or technology expert I am often master of the solution domain, but not of the problem domain. For me it is inevitable to obtain a detailed knowledge of the problem domain. This is even more important when developing product lines or platforms, because in that case lack of common understanding influences more than one product or solution.

How could we address that problem? My recommendation is to introduce a domain model. Of course, I am referring to the problem domain in this context.  A domain model is not just a glossary of terms – a common misconception I am often facing.

A domain model consists of all core concepts (actors, subsystems, components, services, …) relevant within that domain as well as the relationships and interactions between these core concepts.


A large domain typically consists of subdomains. For example, a telecommunications domain for Unified Communication might introduce subdomains such as basic communication or presence. As a consequence, the domain should be partitioned hierarchically into subdomains.  

There are different ways to descible a domain model, from informal approaches to strictly formal definitions such as a domain-specific language. In all cases, stakeholders might select textual or graphical representations, whatever is more appropriate.

Note that I have not assigned the responsibility of introducing a domain model to software engineers. Defining a common domain model should rather be a joint endeavor of all stakeholders, maybe driven by requirements engineers and architects.

If you have ever read definitions of software architecture like the one by ANSI/ISO, you might recognize that architecture definitions match closely with my definition of domain models. First of all, those architecture definitions are insufficient (due to their genericity). Secondly, a domain model is a good starting point for creating the architecture. Take the use cases (black box view) and specify their dynamics using the domain model entities (white box views). Supplement this architecture core with design tactics for non-functional requirements. This will lead to the architecture baseline. Using the domain model also helps you staying focused on the problem domain instead of diving to the solution concepts too early.

Eventually, a domain model defined, understood and agreed by the various stakeholders such as requirements engineers, developers, testers, architects, product managers, customers serves as a fundamental mean for architecture design and communication. 

Of course, the solution domain itself can also be expressed by a domain model. This is why the main task of an architect consists of mapping a problem domain to a solution domain.

Formalizing both to a sufficient extent helps automating this process using model-based software development approaches. Such automation, however, might be too expensive for one-off applications or smaller product lines.

Whenever you are participating in a development process in the presence or future: do not forget to specify the domain model if not already available.


  • Interesting to see that the domain model issue comes up again...
    As I am new to the domain at my new work, it would of course be really good to have a domain model to study. It is probably very common in smaller companies that the knowledge is just in the heads of people and that it would not be necessary or prioritezed to build the domain model. My question is how to argument for developing such a model?
    Best Regards, Björn Nilsson.

    By Blogger bnils, at 3:07 PM  

  • Good question!

    In most of my projects it worked like this: I participated in project meetings where different participants discussed design, architecture and requirements issues. Often when I asked for details I got different statements for the same concepts. Then the participants would easily recognize they had different understanding of domain concepts and needed something like a common language.
    In projects where I am responsible for establishing a systematic architecture design it is even easier because the domain model is one of the fundamental assets.
    In all other projects, there are two different cases: a) the project members are new to the problem domain. In this case I would argue that building a domain model (domain-driven design) is an essential first step, because we cannot come up with a solution for a problem we do not understand. In this case, we need to provide a domain model anyway as the first step.
    In the case, all project members are totally familar with the problem domain, I would recommend to document the domain for all new employees if it is not already documented either implicitly or explicitly. It is a little bit like documenting patterns. Thus, we can use the same arguments (common vocabulary, faster competence ramp-up, easier comunication, ...)
    A domain model is also a first step for developing a DSL if model-driven appraches are planned.

    By Blogger Michael, at 5:14 PM  

  • That was enjoyable to read, thanks for posting it.

    Feel free to visit my blog post; Bing (http://www.bing.com/)

    By Anonymous Anonymous, at 10:03 PM  

Post a Comment

<< Home