Domain driven design provides both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. It provides extensive set of design practices, techniques, and principles to solve the problem.
Domain Model - Domain model is a rigorously organized and selective abstraction of Knowledge.
Continuous Learning
Problem Statement
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing. Translation blunts communication and makes knowledge crunching anemic. Yet none of these dialects can be a common language because non serves all needs.
Ubiquitous Language
The more pervasive the language is used, the more smoothly understanding will flow
With a ubiquitous language, the model is not just a design artifact. It becomes integral to everything the developers and domain experts do together. The Language carries knowledge in a dynamic form. Discussion in the Language brings to life the meaning behind the diagrams and code
Ubiquitous language should be used while writing documentation
To communicate effectively, the code must be based on the same language used to write the requirements - the same language that the developers speak with each other and with domain experts
Model Driven Design
Problem
If the design, or some central part of it, does not map the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mapping between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.
Model driven design discards the dichotomy of analysis model and design to search out a single model that serves both purpose. Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a robust Ubiquitous Language.
Draw from the mode the terminology used in the design and the basic assignment of responsibilities. The code becomes an expression fo the model, so a change to the code may be a change to the model. Its effect must ripple through the rest of the project’s activities accordingly.
To tie the implementation slavishly to a model usually requires software development tools and languages that support a modeling paradigm, such as object oriented programming.
Hands on Modeler
If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraint of implementation. The basic constraint of Model Driven Design that the model supports an effective implementation and abstracts key domain knowledge is half-gone, and the resulting model will be impractical. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that converts the subtleties of coding a Model Driven Design.
With a model driven design, a portion of the code is an expression of the model; changing that code changes the model. Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays on the project. Anyone responsible for changing code must learn to express a model though the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the Ubiquitous language.