Working with DDD - Domain, Model and Language

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 expectations of the code. It shall be easy to understand and read. If the domain experts can understand a snippet of code describing their domain, the room for error shrinks. The standards set by Robert C. Martin in Clean Code is one way to accomplish this.

Ubiquitous Language

A language built around the domain model and is used by all team members to connect all activities the team with the software.
This does not exclude the use of diagrams, symbols and text analysis. These are important tools for finding the model, and describe it before it gets into the code. Texts and informal sketches is a good starting point. We do not need any special design model or specific sets of symbols. This is because we are starting from the domain, the reality, and have to describe it in a way that is shared by developers and those who order the application, the domain experts. It is therefore extremely important to have a common description of reality and a ubiquitous language. This work is the basis for the whole architecture.

Domain Driven Design

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 applications. These are not DDD, they are examples of how to model the domain and separate from other parts of the system. It is important to distinguish these patterns from the technical patterns such as presented by the 'Gang of Four' (Erich Gamma et al.) and think that patterns of DDD rather as abstractions than implementation proposals. The types of patterns often coincide, but we look at them from different directions. From a perspective of ideas and from an implementation perspective. DDD is about creating a sustainable architecture, not primarily about implementation, but for the pragmatic programmer the books presents a lot of implementation ideas to use.

I have learned DDD through practice. A skilled developer introduced me to it and we worked on a project so that it was hands-on learning. Some parts of the model I present here is based more on that practical experience than  Eric Evans ideas. Thus, this may differ from his theoretical model. If you want to learn DDD in an orthodox way: Read his texts! I have read some books on DDD and in  some coming posts I will present a model that is my compromise between theory and practice.

Why is This Blog Called Grouchy-developer

I am almost 50 and has been developing software since I was 14. Year by year I am getting more tired and grumpy about all trendy stuff and hypes. This does not mean that I am against progress, I just get annoyed when people get that religious newly saved missionary personality. The worst kind call themselves "evangelists". You know the judgemental types talking bad about all old stuff and thinks that just they have seen the light.

Naturally a lot of bad software has been written and we learn new stuff, but and tools and languages has evolved. Good and bad developers have always existed.

I also get annoyed with people that are not evolving. If we develop software we should develop ourselves also. This might look as a contradiction to my first paragraph, but it is not. It is the non-humble approach to development that annoys me not the new ideas. A lot of developers just copy old ideas year after year, too afraid to evolve.

I did a for-fun-personality test and became Dr. Perry Cox in Scrubs. It seems that us old professionals gets a bit grouchy with years. We are all fascinated by guys like him and even like Dr. Gregory House. We want to be the brilliant minds solving problems often in a lone wolf kind of way. In reality we might be more like Statler and Waldorf sitting on the balcony in Muppet Show.

"WALDORF: They aren’t half bad.  

STATLER: Nope, they’re ALL bad!"