It had to happen sometime … so here it is, my first blog post.
Cesar and I attended Eric Evans’ two part DDD presentation on Tuesday at JAOO 2006. I was very impressed with the presentation. I believe it helped me get a deeper understanding of some of the more subtle aspects of DDD. I was also particularly impressed with Eric’s low key communication style. I could certainly benefit from both slowing down my delivery and toning down the force with which I deliver my message. Of course I’ve know this for a very long time, maybe I’m finally ready to do something about it … really I’m serious.
Anyways, I’ve collected a number of interesting points that Eric made during his presentation. For the moment, I’m just going list them below. I hope to organize my thoughts about these points in a more coherent fashion for my next blog entry. Here they are:
- DDD is intended to be applied to solving problems where the bulk of the complexity comes from the domain and NOT the technical constraints
- a domain model should be based on concrete scenarios, the more abstract the model the more necessary this condition is
- there are always a multitude of possible models of the domain, choose the model that helps you solve the hard business problems of your application
- be wary of choosing a model that cause too much implementation complexity, in particular be cautious not to shift too much complexity to the O/R mapping layer.
- remember that an object only has meaning in a given context
- create a context map of what your system is, not what you would like it to be
- there are many domains present in any complex business system
- generic sub-domains
- supporting sub-domains
- core domain(s)?
- get a clear understanding of the priorities of the business and use that knowledge to distinguish the core domain from the various generic sub-domains and supporting domains in your system.
- focus your design efforts on the core domain and distill it. The core domain model should be clearly expressed in the code. Fix the flaws in the core domain model before working on improvements to generic and supporting domains.
- seperate your infrastructure code from your core domain model code
- if there are two models co-existing in the same context, seperate them out.
- generic sub-domain and supporting sub-domain code need not be expressed as fully
- seperate the core domain from the rest of the system by surrounding it in its own bounded context.
- supporting and generic sub-domains should also each be surrounded by their own bounded contexts
- escape from the top-down/bottom-up dichotomy. Do both at the same time.
Wow, that’s a lot of stuff. Cesar and I have already spent several hours discussing this stuff and we have tried to apply it on an exploratory refactoring of the core domain for the current project release we are working on. Preliminary results look encouraging…