Scaling Model Driven Development : Introduction

Demos for software tools usually involve some sort of toy project so you can get up to speed with the environment and concepts without having to worry about the details of a complex application. Unfortunately, it's exactly those complex details that rise up to bite you when you adopt a new tool or process and try to use it on a real-world project.

I'm going to do a series of postings about the stuff you don't always notice in the demos, and how it can make the difference between a big mess and a clean scalable model.

You know those scotch-taped-together wall-sized database diagrams with hundreds of tables and an impenetrable maze of relationships between them? Don't do that. There's nothing that says all your classes have to be on the same canvas. You can divide up analysis-level classes into packages exactly the same way you'd divide your Java implementation classes into packages. The familiar principle of reducing coupling between packages applies to models.

A totally standalone model has very low coupling but is otherwise pretty useless. After you divide up your model, you need to hook the pieces back together somehow. But if you just add back in direct relationships then you've simplified the visual design but not the underlying complexity.

In the next post in this series I'll talk about the kinds of coupling that should be allowed between pieces of the model, and the specific modeling artifacts that allow you to incrementally add complexity without breaking previous work. Hopefully it will all lead up to some posts of how to write reusable models, but it depends on how ambitious I'm feeling.