您如何与领域专家协商领域模型?

发布于 2024-07-10 19:57:37 字数 1834 浏览 9 评论 0原文

假设您正在与客户的领域专家合作。 您意识到(或至少有合理的信念)您对他们问题的模型比他们的更清晰。 你如何说服他们应该走你的路。

就我而言,需求的主旨是什么(例如产品的交易系统)是相当清楚的。 根据我的经验和研究,我会推荐一个有两个 TraderParties 的 TradeContract。 每个 TraderParty 购买一种产品并出售一种产品。 如果我必须在 XML 中对组合进行建模,我可能会将其建模为:

<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>

上面只是 Ann 以 20.00 美元从 Bob 处购买的哈利·波特与阿兹卡班的囚徒的模型。 更抽象地说,这是一个两方四足贸易的模型。 为了便于论证,我们假设使用 XML 的系统验证 tradeContract 并协调交易。

如果您的领域专家认为这对他们来说太复杂怎么办? 虽然您可以轻松地承认达到上述领域模型的一些中间步骤,但您如何说服他们最好“咬紧牙关”并尽早使用上述领域模型?

另外:中小企业提出的模型......

领域专家一直在谈论的是我提出的模型,但看起来他们不相信他们的业务流程已经准备好。 (不过,我认为现在有办法凑合)。

他们立即想要的型号是:

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

Ann 赠送的这款型号 20.00 美元。 然后必须输入单独的交易:

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

建模她获得了《哈利·波特》书。 在我看来这相当麻烦,因为我们无法模拟我们的系统是否会欺骗安。 同样,类似的交易碎片也发生在交易合同的鲍勃一方。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梨涡 2024-07-17 19:57:37

我从来没有试图改变该领域的领域专家的思维模式……毕竟他们是专家。 然而,如果我的模型与他们的模型略有不同,那么我确保它仍然可以产生相同的效果。 所以我接受他们的观点,以我自己的方式建模,然后按照他们理解的方式呈现给他们。

总会有从您的技术角度到他们的业务导向角度的转换。 这就是业务分析师的角色。

您的领域专家提出的模型是什么? 如果正如您所说,您的模型捕获了需求,那么请使用您的模型,但向领域专家提供技术性较低的视图......改为使用图表。 他们不必知道从图表生成的 XML。

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.

一杯敬自由 2024-07-17 19:57:37

我从来没有试图改变领域专家的领域心理模型......毕竟他们是专家。

我认为这大部分是正确的。 然而,我知道领域专家不像我那样“理解”的感觉。 虽然很容易将其归因于他们不了解技术方面,但通常这表明开发人员和领域专家之间的沟通没有达到标准。 这可能非常危险。

如果您认为最有效的内容与领域专家想要的内容之间存在巨大脱节,那么您可能错过了他们认为理所当然的领域的关键部分。 尝试从不同的角度询问问题。 有时,如果你遵循另一种推理路径,你会得到不同的结果。 灯泡可能会亮起来,突然间你会对问题有比以前更好的理解,并且因此你将能够与领域专家更好地沟通。

您的领域专家提出的模型是什么?

我认为这也很有趣。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文