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:
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.
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
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.
Comments
Post a Comment