3 ms·

You're right, but I think the hard part is still to find people to bridge the gap between the system experts and domain experts. An extreme example would be if

You're right, but I think the hard part is still to find people to bridge the gap between the system experts and domain experts. An extreme example would be if you're trying to introduce a logistics management system in a shop that was exclusively using pen and paper. You'll need someone with a foot in both world to even get to the point where they can look at your models and/or documentation and say "yes, it matches the business". Or one of the participant in the project will need to become that person (ideally the client, we can dream).

hvidgaard 5y ago
Usually this is solved by including domain experts on the development teams. Their responsibility is not to program, but to document and verify that the test cases are adequate. This is well known, but often ignored because it's expensive.
withinboredom 5y ago
As someone who has done this a few times from pen/paper/excel to actual DDD software, it's really not that hard to shoulder surf and ask lots of questions about edge cases. At least initially. Though my favorite answer to those questions is: "never happens." Thus you end up with `BobSaidNeverHappensException` just to be cute. But really, the software is there to solve a problem, so you end up shoulder surfing while the "expert" uses both systems simultaneously, and they're asking you questions and you're thinking about how you may rearrange the UI from their feedback. It's extremely iterative. The "domain expert" also becomes an expert with the software as they learn about all the things you implement.