I've been reading Domain-Driven Design by Eric Evans as a result of being part of a Lean Book Club (thanks to Darcy for introducing me to the club). I'm only on chapter 6, but it's a good book so far. The main thrust of the book is explaining how a well-developed, well-maintained model of your domain allows you to build better software and how a "ubiquitous language" shared by developers and domain experts is necessary to make sure that model means the same to everyone. The book has already given me some insights into why some of the projects I've been involved with in the past (either as developer or as domain expert) have succeeded or been failures.
As a result a bunch of the book so far deals with talking with domain experts and how to crunch the knowledge you get from them into a useful domain model and ubiquitous language. Much of the rest of what I've read so far deals with how to take that model and build your software around it, continuing to develop the model along the way. Eric says: Use the model at the core of your whole development. I'm really looking forward to the rest of the book and to see how Eric brings all this together.
But then, I was having lunch with someone, and we started talking about user interaction. Specifically how some designers only think in static terms, and don't think about interaction. My mind had been thinking about this Domain-Driven Design stuff, and so I was looking at all software development through a "domain model"-oriented lens. But during this conversation I swung my perspective, and started thinking about how a good designer might interact with good developers.
Interaction-Driven Design?
Is there a similar process in developing a set of interactions and a "ubiquitous language" with designers as there is with domain experts? If a domain model is the result of interactions between developers and domain experts, what's the analogous result of interactions between designers and developers? I'm not sure about exactly what the answers to these questions are, but I'm pretty sure there's a comparison to be drawn.
What's interesting to me is that there might be some consequences that arise if both domain-driven and interaction-driven design need to be used simultaneously. In many cases I can think of, business software is defined by the domain experts, and then used by them. There are cases however where the domain experts have to define the software and then have interaction designers make that domain model accessible to other users. In these cases, you might have to continue the model and ubiquitous language up from the domain experts through the developers to the designers, and then you may have to do more knowledge crunching up there, and then bring it back down to the domain experts. This means you have three parties iterating you model instead of just two.
It may be the case that all three parties can sit down in a room and work it out together, but I worry that you might lose the "implement-ability" of your model if the developers don't sit in the middle. One of the tenets of domain-driven design as Eric Evans sees it is that the model sits at the heart of the software. I imagine that you might lose that without the developers in the middle... but in the middle the developers' jobs get more than twice as hard.
This is a really interesting problem to me, and I don't have any answers right now. Anyone else have thoughts?