Everybody knows the advantages of having domain discussions (if not please read Domain Driven Design by Eric Evans), but still it is one of the most under rated activity in software development. Most teams talk about test driven development, test coverage (this is an over rated activity), estimation, velocity...etc but only few among them talk about domain model. If we do not have a proper domain model, it will be very difficult for any project to be successful no matter what methodology we follow or what driven development we do. I was fortunate to work in a project where we had domain discussions. I was amazed by the change it brought to our project. I knew Domain Discussions have many advantages, but I never knew it will have this much impact in a project until I actually did it. Not only developers were involved in our domain discussions, even business analysts and quality analysts were actively involved. From domain discussions developers were able to better understand business. That way, it was easy for us to make our domain model close to business model. These are the few things I learnt from my project
1. Domain discussion is a MUST for any project
Just Do it!
2. Keep domain discussion casual and flexible.
We want a free flow of communication between team members in these discussions. By keeping it casual and flexible, it will be more like a discussion rather than a meeting.
3. Not only developers, even business and quality analysts should be involved.
This is very important. One of the goals of domain discussion is to create a common language between developers and analysts. If analysts are not involved, this purpose would not be solved and there will be no one to verify if the domain model is similar to the business model.
4. Have domain discussion at least every other week.
By discussing about the domain every other week, all model changes will be communicated within the team. The developers will be able to correct domain earlier from the feedbacks they get from the Analysts.
Friday, October 28, 2005
Domain Discussion
Subscribe to:
Post Comments (Atom)
1 comment:
I agree with what you have written, but I must point out that a domain discussion has to be initiated and led by the analyst, one who understands objects, is able to model the domain prior to these discussions (at least have an outline on a paper napkin for discussion). Only because the analyst is the source of this information.
I also believe that its criticality in a s/w dev process means it needs to formally be part of the process and not done just because a couple of developers envisioned its importance. The same way we have (or should have) retrospectives, standups, TDD, whatever. Which is what you said, I would stress on this a bit more though.
Post a Comment