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.
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
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.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}