Got a very nice “blast from the past” contact (4 levels deep) on LinkedIn. Scott was a member of a team where we went through object modeling for their business application.
The reason I wanted to contact you was two fold:
First for some reason that training has stuck with me more that many trainings and I still go back to the cobweb section of my brain and bring it out every time I have a object modeling task, so thanks you did a good job helping me. This is true for many of the people that were there.
Second as I have been given another task of modeling a large system from scratch I was wondering about how you feel about the Domain-Neutral model that was presented in the training you did for us. I have found it useful over the years but do you still use this model in anything that you design this many years in the future?
Thanks for the help.
And yes, I still do domain modeling the basic way that we did 11 years ago (gulp). I only have my old copy of Together anymore, so I am stuck back in time there. In person, I always use post-it notes, flip-charts, and markers. Once I want to make a computer version, I’ll use different tools for modeling depending on the need. For example, UMLet is a great little simple tool to bang out a quick diagram in no time flat and that can be used by anybody.
Another good approach from what we went through 10 years ago, is to follow the color modeling order to help in the discovery process… that is focusing on the following as you walk through the assorted primary user scenarios:
- First trying to discover what time-sensitive aspects does the business care about most (the pinks)
- Then looking towards the roles that may be at play there (yellows).
- Are there any specific things (like contracts, purchase orders — greens)?
- And finally, any descriptive elements (blues) to go alongside the greens?
For the past 18 months, I am in major love with Ruby, Rails, and MongoDB — plus all of the surrounding tools and community (see my recent blog posts). Ruby the object-oriented language I wanted when I was doing C++, and MongoDB/MongoMapper is the OO-like DBMS that I always wanted. Putting it all together makes for real productive, high-quality, consistent development — I can quickly model out domain things and try them in a working application.
I’ve never done an adequate job of explaining how I like to approach doing just-enough design up front, but you can find a few snippets here:
- Real early writing here
- Getting Started w/ Best Practices & Design Principles
- Agile Development Tips
- Initial Requirements Scoping
Some tips that I find useful when doing initial up-front Domain Modeling (what you are about to do):
- Spend time with subject matter experts and the business/product owners
- Build out as you gather high-level features
- Do breadth first, then depth
- Only go into details when it will help reduce an unacceptable level of risk
That last bullet is key. I like to do just enough up-front work to please the stakeholders and myself that we can answer the question about: how much? and when? to the level of desired specificity. When you attempt a high-level estimate at a given feature, and it is too big for your comfort, then you can get more detail and break it down further so that it becomes acceptable.
If you do not do enough up front, and your estimate is off by an order of magnitude or three, you might upset the client!
On the flipside, if you do too much up front (detailed modeling), then you risk not getting frequent, tangible, working results into the hands of the client soon enough.
It’s a big balancing act.