InfoQ: Domain Driven Design Quickly
Why?
We, in the enterprise development community, especially the web development community, have been tainted by years of hype that took us away from proper object oriented software development.
- Eric Evans' Blue Book - Domain-Driven Design: Tackling Complexity in the Heart of Software
- Jimmy Nilsson’s Applying DDD
- http://groups.yahoo.com/group/domaindrivendesign
Introduction
Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas.
A domain is something of this world. It cannot just be taken and poured over the keyboard into the computer to become code. We need to create an abstraction of the domain.
What is this abstraction?
- It is a model, a model of the domain.
- It is not a particular diagram; it is the idea that the diagram is intended to convey.
- It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge.
We even need to leave some parts of the domain out. A domain contains just too much information to include it all into the model. And much of it is not even necessary to be considered.
A model is an essential part of software design. We need to communicate this model with domain experts, with fellow designers, and with developers. There are different ways to do that.
How is the model communicated?
- One is graphical: diagrams, use cases, drawings, pictures, etc.
- Another is writing. We write down our vision about the domain.
- Another is language. We can and we should create a language to communicate specific issues about the domain.
Code design
When we have a model expressed, we can start doing code design, working on the details. Here code design patterns come handy, and they should be applied when necessary. Good coding techniques help to create clean, maintainable code.
While Agile advocates recognize the importance of design decision, they resist upfront design. Instead they employ a great deal of implementation flexibility, and through iterative development with continuous business stakeholder participation and a lot of refactoring, the development team gets to learn more about the customer domain and can better produce software that meets the customers needs.
And while the waterfall approach may lead to over-engineering, the fear of over- engineering may lead to another fear: the fear of doing a deep, thoroughly thought out design.