Solutions Architect and DevOps Consultant
Domain Driven Design and Ubiquitous Language
Domain-Driven Design (DDD) is an approach to drive complex software projects using a set of principles, software design practices and techniques by directly aligning the code with the concepts in the domain (Evans2003). The concept was established by Eric Evans in his book “Domain-Driven Design, tackling complexity in the heart of software”. Vaughn Vernon notes that Evans' book “is essentially a large pattern language” (Vernon2013).
The basic set of object-oriented Design Patterns became popular by the "Gang of Four" (Gamma1995). Thereafter, in the context of enterprise applications, Martin Fowler (Fowler2002) presented a set of higher level patterns usually applied in enterprise application development. Eric Evans takes the concept further by placing the Domain Model in the heart of enterprise applications and presenting a set of strategic and tactical software design patterns tied together by a Ubiquitous Language.
Martin Fowler described the Domain Model as “an object model of the domain that incorporates both behaviour and data” and coined the term Anemic Domain Model to describe the opposite. By applying domain-driven design in a software project, the focus shifts from the Database to the Domain Model leading to more maintainable and clear designs (Nilsson2006). In the prominent software design and implementation paradigm (in Python but also in the Java EE world) code is organized in procedures that make direct or indirect calls to the database. Those procedures many times are disguised as object methods that operate against other objects that hold the data and have no business logic. This is referred by Fowler as the Transaction Script and is the base of the Anemic Domain Model.
Domain-driven design is usually described in the context of statically-typed and object-oriented programming languages like Java and C#. In contrast, practical resources and examples are sporadic in dynamic programming languages such as Python. In addition, there is often strong criticism in Python discussion forums that many software design patterns are not applicable in Python because the patterns are circumventing weaknesses of statically typed programming languages like Java and C++.
Ubiquitous language
A prominent element within Domain-Driven Design is the Ubiquitous Language. Briefly, the term refers to the shared language exercised by a team of domain experts and software developers which is in addition reflected in the code (Evans2003).
In software projects, domain experts and software developers have to collaborate in order to describe a model of the domain. Typically, domain experts use the business terminology to describe the domain. However, many times they tend to use more than one words for the same thing or the same word to mean many different things depending on the context. On the contrary software developers translate the input from the users into abstract concepts, algorithms, inheritance, database tables in order to support the delivered software. Furthermore, domain experts have to translate a developer's technological jargon back to their business concepts in order to understand the software being implemented. This leads both collaborators being lost in translation.
In order to bridge the gap a business analyst might be employed to act as the translator between the domain experts and the developers. However, this could lead to two different spoken languages and if the analyst misinterprets a requirement the final application might not fulfil its goal which could be discovered quite late (Haywood2009).
Many teams recognize the deficiencies of using a different vocabulary to describe the Domain Model and intuitively commit in using a shared language. This language needs to be ubiquitous and evolve out of the collaboration between domain experts and software developers (Evans2003). The developers should reflect the Ubiquitous Language in the source code, not only in naming classes and attributes but also when coding behaviour (Evans2003). Due to the use of a common language, whenever there is a misconception the developers could share their thoughts by presenting their diagrams (simple sketches or even UML diagrams) while the domain experts could spot easily mistakes and contribute knowledge about the domain (Nilsson2006).
Whenever the shared language changes, this is an indication of a modification in the domain which should trigger code transformations (Evans2003). The team should work hard to keep the Ubiquitous Language clear from ambiguities and in sync with the software solution (Nilsson2006) by re-factoring the code to conform to the new model (Evans2003).
References
- Evans, E. (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston: Addison-Wesley.
- Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995) Design Patterns: Elements of Reusable Object-Oriented Software. New York: Addison-Wesley.
- Fowler, M. (2002) Patterns of Enterprise Application Architecture. Boston: Addison-Wesley.
- Haywood, D. (2009) Domain-Driven Design Using Naked Objects. Raleigh: Pragmatic Bookshelf.
- Nilsson, J. (2006) Applying Domain-Driven Design and Patterns. Boston: Addison-Wesley.
- Vernon, V. (2013) Implementing Domain-Driven Design. Boston: Addison-Wesley.
This post is an excerpt of my MSc Thesis titled "Applying Domain-Driven Design in Python - designing a self-hosted Read-it-Later service" (January 2014).