Resharpen Domain Driven Design – Chp. 1 & 2 Notes

This entry is part 1 of 2 in the series Domain Driven Design

As part of resharpening the blade I am looking back at Eric Evans 2003 Domain-Driven Design.

Chapter 1

Ingredients of Effective Modeling
- Sharing a common Language
- Developing a knowledge-rich model
  - the model was used both for solving problems but also for understanding any limitations til current
- Reductive Model: as the model became clearer the scope of the model could also be decreased
- Experimentation Lab: The model was used as a testing ground and lab for futher and future review
Knowledge Crunching
- old style is to tell the developer what to build and they can built it. Maybe even keep it clean but it will not grow past that and it can’t add on new powerful collaborative features.
- The process has to be collective and iterative and conjoined ; Dev & business.
Continuous Learning
- Technical Knowledge, general domain-modeling skills and domain specific knowledge
Knowledge-Rich Design
- it is imperative not only to find the nouns and verbs, but have a natural way to express the entire model

Ubiquitous Language
- It is necessary to share in one language to describe and describe the domain
- use the mode as the backbone of language
Modeling Out Loud
- Be intentful in describing and using the model in day to day speech to test it out and make it functional
One Team, One Language
- Don’t take no for an answer. there must be common ground to speak on what is being built.
Documents and Diagrams
- The vital detail about the design is captured in the code
- persistent form documents lose their connection from the flow of a project, and are left behind because of the evolution of code and the evolution of the language of the project
- Diagrams are not the model
- Documents should complement code and speech
Explanatory Models