How do you negotiate a domain model with your domain experts?

Question

Suppose you're working with a customer's domain experts. You realize (or at least have a reasonable belief) that your model of their problem is clearer than theirs. How do you convince them that they should go your way.

In my case, it is fairly clear what the main thrust of the requirements are (e.g. a trading system for a product). Based on my experience and my research, I would recommend a TradeContract which has two TraderParties. Each TraderParty buys one Product and sells one Product. If I had to model the composite in XML, I might model it as:

<tradeContract>
    <id>1234</id>
    <tradeParty>
       <id>1</id>
       <name>Ann</name>
       <long type="money" value="20.00"/>
       <short reference="book.123"/>
    </tradeParty>
    <tradeParty>
       <id>2</id>
       <name>Bob</name>
       <long reference="book.123"/>
       <short type="money" value="20.00"/>
    </tradeParty>
    <product>
       <id key="book.123">123</id>
       <type>book</type>
       <title>Harry Potter and the Prisoner of Azkaban</title>
    </product>
</tradeContract>

The above simply models that Ann bought Harry Potter and the Prisoner of Azkaban from Bob for $20.00. More abstractly, this models a two-party, four-legged trade. Let's just assume for argument's sake the system that consumes the XML validates the tradeContract and orchestrates the trade.

What if your domain experts feel this is too complicated for them? While you can readily acknowledge some intermediate steps to get to the above domain model, how do you persuade them that it's better to "bite the bullet" and use the above domain model sooner rather than later?

ADDITION: the SME's proposed model ...

What the domain experts keeping talking about is the model I came up with, but it looks like they don't believe their business process is ready for it yet. (Still, I think there are ways to make do now).

The model they want immediately is:

<tradeParty>
   <id>1</id>
   <name>Ann</name>
   <transaction type="long" product="money" value="20.00"/>
</tradeParty>

This models that Ann gave away $20.00. Then a separate transaction has to be entered:

<tradeParty>
   <id>1</id>
   <name>Ann</name>
   <transaction type="short" product="book" reference="book.123"/>
</tradeParty>

To model that she acquired the Harry Potter book. Quite cumbersome in my opinion because we cannot model whether our system will cheat Ann. Likewise a similar kind of fragmentation of transactions happens to the Bob's side of the trade contract.

Answer 1

I never try to change the domain experts mental model of the domain...they are the experts after all. However, if I model it slightly different from their model then I make sure that it can still produce the same effect. So I accept their view, model it my own way and then present it to them the way they understand it.

There is always going to be that translation from your technical perspective to their business oriented perspective. That is the role of your business analyst.

What is the model that your domain expert came up with? If as you say your model captures the requirements then use your model but present the domain expert with a less technical view...use diagrams instead. They do not have to know the XML that is generated from the diagram.

Answer 2

I never try to change the domain experts mental model of the domain...they are the experts after all.

I think this is mostly true. However, I know the feeling of thinking that the domain experts don't "get it" as well as I do. While it is easy to just chalk this up to them not understanding the technical aspects, often times it is a sign than the communication between the developer and the domain experts isn't up to par. This can be pretty dangerous.

If there is a huge disconnect between what you think would work best and what it is the domain experts want, it is possible that it is you who is missing a key part of the domain that they maybe take for granted. Try asking about the problem from different angles. Sometimes you will get a different result by following another path of reasoning. Light bulbs may go on, and suddenly you'll have a far better understanding of the problem than you did before and you'll be able to communicate better with the domain experts because of it.

What is the model that your domain expert came up with?

I think this would be very interesting to see as well.