我有一个场景，它涉及一台自动售货机，然后要求我们创建以"对问题域建模"。我对模特的介绍非常松散，希望有人能澄清这一点。
从研究来看，问题域似乎只是一个域模型，而这个域模型实际上是一个UML类图。
我看到的例子看起来几乎是带有客户实体、订单实体等的数据库模式。
我只是不确定到底有什么不同。
所以我只是想知道我是否走在了正确的轨道上，有人介意详细说明这一点，或者也许给我一个简洁的定义。谢谢
"问题域"只是你感兴趣的东西。在你的情况下，它是自动售货机所做的所有事情，以及谁与它交互。
它可以归结为用例的集合，这些用例可以在用例图中进行图示。自动售货机是做什么的？它从买家（演员）那里拿走硬币，给零钱（也许……所以确保你理解"扩展点"），吐东西（总是，因为我们不在现实世界中），等等。然后，也许你可以和另一个演员一起发挥创意。维修人员拿出钱，加零钱，给机器加油，运行诊断堆栈，等等。每一个都是一个用例。将它们组合到一个用例图中。
如果您想详细了解每个用例的作用，请使用活动图。每个用例一个。
任何系统（无论是否为软件，无论是否建模）都有结构和行为方面。
结构方面是系统的非时间约束方面，例如系统由哪些类组成，它们的关联和依赖关系，它们如何划分为子系统等。这些元素中的大多数通常被称为分类器。
行为方面显示了这些结构方面如何随着时间的推移协同工作，以实现系统的目标，如方法、状态机、工作流、用例实现等。
结构和行为方面是您在编写代码或创建模型时指定的内容。
对象，根据定义是类的实例。这意味着对象是系统执行时实际存在的"事物"。因此，您不会对对象进行编程；您对一个类进行编程，该类在执行时被实例化为一个或多个对象。
然而，在许多建模语言中（但在编程语言中并不常见），您也可以对场景的规范进行建模，这些规范显示了对象的规范及其交互方式，例如，在UML中，您可以创建一个对象图，显示对象系统（即实例化类）在执行过程中如何结构化和协作的一个示例。
现在，一个系统总是努力实现它周围的一个或多个目标。周围由人和/或与系统交互的另一个系统（参与者）组成。系统所处的"环境"或"背景"通常被称为"域"。
这些"行动者"有一个他们希望系统帮助他们解决的"问题"。当这个问题被建模时，人们将该模型称为系统的"问题域模型"。它说明了问题域的逻辑结构和行为方面，而没有说明它将如何在系统的特定实现中实现。也就是说，它不是指实现方面，如Java、SQL、主键、事务、反射、角度等；相反，它专注于领域的核心结构，如订单、各方、合同、产品等。
问题域模型是系统开发人员与系统付费人员或系统所有者和用户之间最重要的"合同"之一。它使你们所有人都有可能以同样的方式理解要解决的问题，并确保你们都在使用相同的概念来推理。由于从定义上讲，它不是一个技术性的人工制品，所以你应该尽可能使用简单的符号（但仍然严格而清晰）来描述它，这样非软件专业人员也可以理解并同意它。类图（从所有技术细节中剥离）和用例图是可用的两种表示技术。但是对象图和活动图也可以派上用场。
如果你对此感兴趣，我会在Udemy上提供一门高级概念域建模课程。这里是链接和90%关闭代码：https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29
问候根据