Lately I've been working on some large legacy modernization projects with MAKE's MDD tooling. These projects have upwards of 400 entities in their domain (read: minimum 400 database tables). With such a large application domain it's common to have large, complex domain diagrams which are often at the wrong level of granularity for programming tasks.
I found myself creating small, purpose-specific diagrams showing only those things that were relevant to the task at hand. These diagrams would get tweaked and maintained as my understanding of the task and domain evolved. While maintaining diagrams is not really all that hard, it is time-consuming and distracting.
After some thinking I realized that the answer to developer productivity was sitting right in front of me: Mylyn task context-driven diagrams. Why can't the MDD tooling create and maintain a domain diagram based on the interesting domain elements in the active Mylyn context? There would be no need to create or maintain such a diagram manually: it would always exist, and it would always show only those items that are relevant to the currently active task. Suddenly, purpose-specific diagrams become implied, easy, expected.
I realized that a few simple rules could make such a diagram really work:
- domain elements in the Mylyn context always appear in the diagram
- associations between elements in the diagram are always shown
- removing an element from the Mylyn context causes it to be removed from the diagram
- adding an element to the diagram causes it to be added to the Mylyn context
- diagram elements are positioned according to a default layout algorithm, but remember their positioning if moved manually
- diagram state is saved and associated with the Mylyn task id, such that it is restored when the task is re-activated
- switching active tasks automatically resets the diagram to correspond to the new active task
As my Mylyn task context evolves with its decaying interest model the diagram becomes ever more pertinent. Mylyn landmarks prevent those really essential things from disappearing, other things come and go as needed.
Now that I've been working with automatic domain diagramming I wonder how I ever got by without. Context-driven diagrams are now an essential part of my toolkit that let me focus on the task at hand without distraction.
- Faster Feedback Loop on Code Reviews
- Surfacing Abstractions in Code Reviews
- Architecting for the Value Stream
- ELK Stack for Improved Support
- Article Index
subscribe via RSS