title: Logical versus physical design
body: <p>I have a very general design question, but I'll frame it in concrete terms with an example.</p>
  
  <p>Suppose you're working on embedded software for a digital printer.  The machine has 4 print heads (for each of the C, M, Y, K colors).  Each print head performs the same task: fetching toner and putting it on the page.</p>
  
  <p>At runtime, we could organize our API in two distinct ways.  Either we follow a logical (aka "functional" or "process") design, so that client software can control the printing process across all print heads (e.g. change the brightness of all colors at once).  Or we follow a physical design, so that client software can control each print head individually (e.g. change the brightness of only the magenta color).</p>
  
  <p>This is a classic dilemma in software design:  We either organize by activity or by architecture.  By function or by form.  My question is:  are there any solid criteria for choosing one over the other?  Different projects will choose differently and can both be right depending on their own situation; so I'm not asking which is best, only how to choose.  E.g. I would be interested in your ideas about loose coupling, maintainability, layering, role-oriented design, architectural design patterns, etc.</p>