In a previous post, I tried to make a point. I think I did make the point, but it was kind of hard to decipher. So, here's a (please God I hope more succinct) stab at it.
Learning to be a good programmer takes skill and effort (the rest of us get by on looks and charm). Learning patterns, OO principles, and the like are all ways that you can try to make yourself a better programmer.
Learning to program within a domain (whether you explicitly follow DDD and have a Ubiquitous Language or not) requires learning something about the domain. Or at least whatever piece of it you are working on.
*But* in most/many/some situations, the true Subject Matter Expert (SME) isn't a programmer. And so they have to 'dumb it down' for the development team, because the members of the development team can't be expected to know what the SME knows.
I think this has a lot to do with why software development fails often times. The SME can tell you after the fact that the software didn't deliver what they wanted. Things like DDD/TDD/BDD/<insert xDD here> are supposed to help in this area, and I suppose they do, but often times, the SME has implicit knowledge that they don't know they need to make it explicit, e.g., 'When I said I wanted X, of course I meant that Y and Z should also be true'.
At times, there seems to be this assumption that by having a back-and-forth conversation between the SME and the dev team, you can have user stories that just work. But there is a reason why you have to go to school to get a degree in Finance (as an example). You can't just have 'conversations' and expect a developer who doesn't have the educational background to understand what the SME is saying.
In the best case scenario, the developer will be able to fake it enough and ask the right sort of questions along the lines of 'what do you want this screen to show', and that is actually a very good skill to have. But it is a reactive skill, not a proactive one.