I have been reading Sandi Metz’s Practical Object-Oriented Design in Ruby - a generally fantastic book - and I came across a passage that really struck me:
Domain objects are easy to find but they are not at the design center of your application. Instead, they are a trap for the unwary. If you fixate on domain objects you will tend to coerce behavior into them.
Sandi is referring to the design of your software at the code level, but it occurred to me that this kind of thinking influences every level of the software design. I often start the work of understanding a domain by enumerating the nouns that inhabit it, “Ok, so I know there is a customer and a manager and an office…” These are typically the roles that will end up in my user stories and features - “As a customer / Given that …” This is probably a decent strategy to get the ‘lay of the land’, but I think there is a potential pitfall; if we mentally pigeonhole our users into these labeled roles and only think of them that way then we can forget that these are actually people, not roles.
This is a problem because, as with any commonly used label, it’s very easy to import our stereotypes of a generic “customer” or “manager” and to design software with these stodgy images in mind. As with a fixation on domain objects, this approach tends to yield stiff, lifeless design - more machine than human. I remember hearing that some BDD practitioners substitute people’s names for generic role labels like ‘customer’ in their user stories. They then create detailed personalities, needs, etc. for them as a sort of aggregate picture of that type of user, similar to how market researchers distill demographics into named archetypes. I am going to experiment with this as it seems a good way to humanize our stakeholders and thereby feed our imaginations richer material with which to synthesize features.