Naming (Or How Names Can Be Ambiguous)
Join the DZone community and get the full member experience.Join For Free
i've done a bunch of software architecture sketching sessions with teams over the past few months and, although we cover a lot of ground, here's a tip to improve your diagrams. if naming is one of the hardest things in software development , resist the temptation to have a diagram full of boxes that only contain names.
a really simple way to add an additional layer of information to an architecture diagram (and to remove any ambiguity) is to annotate boxes with a very short statement of what their responsibilities are. a bulleted list ( 7 ± 2 items ) or a short sentence work well. provided it's kept short (and using a smaller font for this information can help too), adding responsibilities onto diagrams can help provide a really useful "at a glance" view of what the software system does and how it's been structured. here's an example ... which diagram do you prefer?
if you're interested in how to sketch software architectures, you can...
- buy my book .
- join me at sdd 2014 in london , goto chicago 2014 or goto amsterdam 2014 .
- download the slides from one of my sketching talks.
- watch the video of a recent evening talk i gave at skills matter.
- book me for an in-house session.
Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.