UML中的领域模型？

我阅读了有关域模型及其重要性的文章，我有以下疑问：

• 使用域模型可以解决什么样的问题？换句话说，对于每个问题，我应该建立一个域模型吗

• 据我所知，领域模型是用类图表示的。类图和领域模型之间没有区别吗

• 我还想了解词汇表以何种方式与域模型相关

使用域模型可以解决什么样的问题

几乎任何您想要/需要为其提供软件解决方案的问题都可以建模。事实上：无论你怎么做，你都必须以某种方式、形状或形式“模拟”你的问题领域。如果您不以某种方式在软件中捕获问题的规则和策略，那么最终系统将不太可能满足其预期需求

换句话说，对于每个问题，我应该建立一个域模型吗

这取决于“构建域模型”的含义。见上下

据我所知，领域模型是用类图表示的。类图和领域模型之间没有区别吗

类图是对域建模的一种方法。实际上，它们是对一个域的一部分进行建模的一种方法。类图的主要优点是，它明确而清晰地公开了问题空间中的关系。有一种观点认为，域的语义主要是通过概念（类）之间的关系产生的，而不是通过类本身。如果你接受这种观点，那么你可能会发现类图很有用

但是请注意，类图只捕获域的结构元素：类、属性和关系。CD不捕捉行为。如果要以任何有用的方式对问题空间进行建模，领域模型需要结构和行为。因此，您需要用一些行为描述来扩充类图；e、 g.状态模型和/或动作

还有其他方法可以对域进行建模。它可以是一组java/c类。这种方法的主要缺点是减少了对关系的重视。与类图不同，OO语言不提供关系作为第一类构造。其优点是编程语言环境（编辑器/编译器/库/语言运行时）为定义域的行为方面提供了比大多数建模工具更好的支持

更一般地说，没有规则规定域模型必须遵循OO范式。它可以是Haskell或OCAML中的一组函数和类型。或者它可以是一些微分方程或其他数学结构

关键是模型——无论表达方式如何——提供了问题空间的描述。为了有用，描述将不完整-它将只捕获与系统需求相关的问题空间中的属性子集。然而，为了有用，它应该是正确的——捕获的概念和行为应该准确地反映正在建模的世界

我还想了解词汇表以何种方式与域模型相关

您可以将域模型视为生成形式化且高度结构化词汇表的一种方法。实际上，它也抓住了一些语法；e、 g.“所有权”关系的参与者必须是狗和人；不是两只狗，也不是一个人和一把勺子

这就是埃里克·埃文斯（Eric Evans）在《圣经》中所说的“无处不在的语言”。这意味着模型中使用的术语应准确反映所建模问题的术语。因此，如果现实世界的领域专家使用“人”和“狗”，那么模型就不应该使用“智人”和“狗”。理由很简单：如果开发人员（建模者）使用与领域专家相同的术语，那么误解的可能性就会小得多。因为每个人都在使用具有共同含义的熟悉词汇，所以这也会带来更高效、更愉快的对话

摘要

• 域模型是一种抽象。它代表了系统解决的实际问题所固有的概念、规则和策略的子集
• 类图是表示域模型的结构方面的一种方法。它不捕捉动态方面。这些同样重要
• 还有其他方法可以对域进行建模。它们并不局限于面向对象的范例
• 领域模型应该是问题空间的结构化词汇表。它应采用该领域专家使用的术语

---

hth.

非常有用的信息@sfinie谢谢<代码>优点是编程语言环境为定义域的行为方面提供了比大多数建模工具更好的支持您能稍微澄清一下上面的引用吗？以前，我认为领域模型只与统一过程（UP）相关，但现在，我可以随时随地使用它。对吗？UML在为操作提供支持方面一直很弱；if/then，while循环，计算等等，这意味着很难在UML中定义行为逻辑。该标准现在包括了各种选项（动作语义&alf），但对于工具来说还为时过早。相比之下，编程语言已经提供了很好的支持。是的，关于领域模型没有RUP的具体内容。例如，它是领域驱动设计的核心。嗯。