the Sourcerers Orchard

In addition to having a common language with domain experts, the developers need a common language. There are a number of standard patterns that reoccur in DDD. Characterization of these is a vital in the domain-driven design. Sometimes it's pretty obvious which category a particular class belongs to but other times it's not so easy to sort out the different building blocks of a model-driven design. Using standard building blocks helps. Application Context In the appli c ation- c ontext all the objects that depend on the infrastructure that the application runs in are created . This allows to easily replace parts of the system, such as which database to use. Do not mix this together with the bounded context. The application initiates the application and is a class, while the bounded context is about working on the conceptual level often realized at as packages in Java . A good way to make the application context is to have a generic context that give singleton insta...

Now we are entering the main part of DDD: To model the domain. Context Context - The environment in which a word or proposition that determines it's meaning. Bounded contexts are a breakdown of the domain. All major projects covering different sub-models and when the code based on the different models are combined, it can become complex. Communication to and from, and within the team gets confusing. It is often not clear in which context one model should not be applied. The model must be divided in limited contexts with clear interfaces to other parts of the system. Each bounded context shall be independent of the others. When a number of people working in the same bounded context, there is a risk model becomes fragmented. The more people who are inside, the greater the problems. This breaks down the system into smaller contexts and eventually lose the integration and coherence. There must be a process of merging all code and other artifacts with automated testing. Use the ...