the Sourcerers Orchard

There are a lot of concepts that is important for DDD. The most important ones are the Domain, the Model and the Ubiquitous Language. Domain A sphere of knowledge (ontology), influence or activity. The subject that the user is working a program on the domain of is software. The domain in DDD is the problem space. The corresponding solution space is called the model. Model A system of abstractions that describe selected aspects of a domain and can be used to solve the problems associated with that domain. With DDD, we are looking to create models of the domain. Things which often places great effect at the beginning of a project, such as persistence, user interface and protocol. Model does not mean a graph or set of graphs e.g. UML. Charts are useful, but they are not the model, just different views of the model. The model is one that we choose to implement in software, represented in the code used to construct the system. The code itself is the model. This gives certain expec...

A couple of year old trend is DDD. I love a lot of the ideas behind DDD, but the people talking about it can be really annoying. They talk a lot how DDD is not the strategic and tactical patterns that most of the books on the topic covers on 90% about the pages. They have seen some kind of light that is greater. I like to take a more pragmatic look of it: What can I use of this to build great software. Domain Driven Design (DDD) is a method of creating a software architecture. The basis for domain-driven design is to start from domain experts' knowledge and allows the software a model of the domain and its processes: base the design on a model of the domain  you have a creative collaboration between developers and domain experts to refine a model  establishing a ubiquitous language shared between developers and domain experts  The idea is to start from the business and not in the technical part. Domain-driven design also presents a set of patterns for building ap...